Design a Tic Tac Toe game that:

• Supports configurable board size (N N)

• Supports 2 players

• Validates moves

• Detects win efficiently

• Detects draw

• Logs moves

• Is extensible (AI, multiplayer, new win strategies)

• Uses proper design patterns

• Is written in C++ (single-threaded)

📌 2. Functional Requirements

Core Features

• Create game with size N

• Add 2 players

• Players make alternate moves

• Validate moves

• Detect winner

• Detect draw

• Display result

• Log game events

• Allow restart (extensible)

📌 3. Non-Functional Requirements

• Clean architecture

• O(1) win detection

• Extensible strategy

• Easy to add AI

• Maintainable code

• Testable components

📌 4. High-Level Architecture

Game
  Board
       Cell
  Player
  WinningStrategy
  Logger
  GameState

📌 5. Design Patterns Used (With Clear Reasoning)

📌 6. Algorithms Used

🟢 1. O(1) Winning Algorithm (Optimized)

Instead of scanning entire board after every move (O(n)):

We maintain:

rowCount[n]
colCount[n]
diag
antiDiag

For Player X +1 For Player O -1

If:

abs(rowCount[i]) == n
OR abs(colCount[i]) == n
OR abs(diag) == n
OR abs(antiDiag) == n

Winner found

Complexity:

• Move: O(1)

• Win check: O(1)

🟢 2. Move Validation

• Check bounds

• Check if cell empty

Complexity: O(1)

🟢 3. Draw Detection

if totalMoves == n*n

📌 7. Complete C++ Implementation

🔹 ENUMS

enum class Symbol { X = 1, O = -1 };
enum class GameStatus { IN_PROGRESS, DRAW, WIN };

🔹 Observer Pattern

class Observer {
public:
    virtual void update(string message) = 0;
    virtual ~Observer() {}
};

🔹 Singleton Logger

class Logger : public Observer {
private:
    Logger() {}
public:
    static Logger& getInstance() {
        static Logger instance;
        return instance;
    }

    void update(string message) override {
        cout << "[LOG] " << message << endl;
    }
};

🔹 Cell Class

class Cell {
public:
    int row, col;
    Symbol* symbol;

    Cell(int r, int c) : row(r), col(c), symbol(nullptr) {}

    bool isEmpty() {
        return symbol == nullptr;
    }

    void setSymbol(Symbol* s) {
        symbol = s;
    }
};

🔹 Board Class

class Board {
private:
    int size;
    vector<vector<Cell>> grid;

public:
    Board(int n) : size(n) {
        for(int i=0;i<n;i++) {
            vector<Cell> row;
            for(int j=0;j<n;j++)
                row.emplace_back(i,j);
            grid.push_back(row);
        }
    }

    int getSize() { return size; }

    bool placeMove(int r, int c, Symbol* s) {
        if(r<0 || c<0 || r>=size || c>=size)
            return false;
        if(!grid[r][c].isEmpty())
            return false;

        grid[r][c].setSymbol(s);
        return true;
    }
};

🔹 Strategy Pattern Winning Strategy Base

class BaseWinningStrategy {
protected:
    int size;
public:
    BaseWinningStrategy(int n): size(n){}
    virtual bool checkWin(int row, int col, Symbol sym)=0;
    virtual ~BaseWinningStrategy(){}
};

🔹 Efficient Winning Strategy (O(1))

class EfficientWinningStrategy : public BaseWinningStrategy {
private:
    vector<int> rowCount;
    vector<int> colCount;
    int diag=0, antiDiag=0;

public:
    EfficientWinningStrategy(int n)
        : BaseWinningStrategy(n),
          rowCount(n,0), colCount(n,0) {}

    bool checkWin(int row, int col, Symbol sym) override {
        int val = (int)sym;

        rowCount[row]+=val;
        colCount[col]+=val;

        if(row==col) diag+=val;
        if(row+col==size-1) antiDiag+=val;

        if(abs(rowCount[row])==size ||
           abs(colCount[col])==size ||
           abs(diag)==size ||
           abs(antiDiag)==size)
            return true;

        return false;
    }
};

🔹 Factory Method Player Creation

class Player {
protected:
    string name;
    Symbol symbol;

public:
    Player(string n, Symbol s): name(n), symbol(s){}
    virtual pair<int,int> makeMove()=0;
    Symbol getSymbol(){ return symbol; }
    string getName(){ return name; }
    virtual ~Player(){}
};

class HumanPlayer : public Player {
public:
    HumanPlayer(string n, Symbol s)
        : Player(n,s){}

    pair<int,int> makeMove() override {
        int r,c;
        cout<<"Enter row and col: ";
        cin>>r>>c;
        return {r,c};
    }
};

class PlayerFactory {
public:
    static shared_ptr<Player> createPlayer(
        string type, string name, Symbol s) {
        if(type=="HUMAN")
            return make_shared<HumanPlayer>(name,s);
        return nullptr;
    }
};

🔹 Decorator Pattern AI Extension

class PlayerDecorator : public Player {
protected:
    shared_ptr<Player> player;
public:
    PlayerDecorator(shared_ptr<Player> p)
        : Player(p->getName(), p->getSymbol()),
          player(p) {}
};

class AIPlayerDecorator : public PlayerDecorator {
public:
    AIPlayerDecorator(shared_ptr<Player> p)
        : PlayerDecorator(p){}

    pair<int,int> makeMove() override {
        cout<<"AI making move...\n";
        return {0,0}; 
    }
};

🔹 Game Class

class Game {
private:
    Board board;
    shared_ptr<Player> p1;
    shared_ptr<Player> p2;
    shared_ptr<Player> current;
    unique_ptr<BaseWinningStrategy> strategy;
    GameStatus status;
    int moves=0;

public:
    Game(int n,
         shared_ptr<Player> pl1,
         shared_ptr<Player> pl2)
        : board(n), p1(pl1), p2(pl2),
          current(pl1),
          strategy(make_unique<EfficientWinningStrategy>(n)),
          status(GameStatus::IN_PROGRESS) {}

    void play() {

        while(status==GameStatus::IN_PROGRESS) {

            auto move=current->makeMove();
            bool placed=board.placeMove(
                move.first, move.second,
                &current->getSymbol());

            if(!placed){
                cout<<"Invalid Move\n";
                continue;
            }

            Logger::getInstance().update(
                current->getName()+" moved");

            moves++;

            if(strategy->checkWin(
                move.first, move.second,
                current->getSymbol())) {

                status=GameStatus::WIN;
                cout<<current->getName()<<" Wins!\n";
                break;
            }

            if(moves==board.getSize()*board.getSize()){
                status=GameStatus::DRAW;
                cout<<"Game Draw\n";
                break;
            }

            current=(current==p1? p2:p1);
        }
    }
};

🔹 Builder Pattern Game Builder

class GameBuilder {
private:
    int size;
    shared_ptr<Player> p1;
    shared_ptr<Player> p2;

public:
    GameBuilder& setSize(int n){
        size=n;
        return *this;
    }

    GameBuilder& setPlayer1(shared_ptr<Player> pl){
        p1=pl;
        return *this;
    }

    GameBuilder& setPlayer2(shared_ptr<Player> pl){
        p2=pl;
        return *this;
    }

    unique_ptr<Game> build(){
        return make_unique<Game>(size,p1,p2);
    }
};

🔹 Main Function

int main(){

    auto player1=PlayerFactory::createPlayer(
        "HUMAN","Alice",Symbol::X);

    auto player2=PlayerFactory::createPlayer(
        "HUMAN","Bob",Symbol::O);

    auto game=GameBuilder()
                .setSize(3)
                .setPlayer1(player1)
                .setPlayer2(player2)
                .build();

    game->play();

    return 0;
}

📌 Complexity Analysis

🧵 Multithreading Problems in the Tic Tac Toe Implementation

Our current implementation is single-threaded and assumes:

• Only one thread calls game->play()

• Only one thread makes moves

• No external UI thread

• No AI thread

• No logging concurrency

If we allow:

• Multiple threads (UI thread + AI thread)

• Network multiplayer

• Async logging

• Spectator updates

👉 The current design becomes unsafe.

Below is a complete breakdown of every multithreading issue and its proper fix.

🚨 PROBLEM 1: Race Condition on Board State

Where?

bool placeMove(int r, int c, Symbol* s)

Two threads:

Thread A: places move at (0,0) Thread B: places move at (0,0)

Both check:

if(!grid[r][c].isEmpty())

Both see empty Both write Result: corrupted state

Solution: covered in our course.

🚨 PROBLEM 2: Race Condition in Winning Strategy Counters

In EfficientWinningStrategy:

rowCount[row] += val;
colCount[col] += val;
diag += val;

Two threads updating simultaneously lost updates.

Example:

Thread A: rowCount[0] = 1 Thread B: rowCount[0] = 1 Final: 1 (should be 2)

Solution : covered in our course.

🚨 PROBLEM 3: Race Condition on moves Counter

In Game class:

moves++;

Two threads increment lost update.

Fix: covered in our course.

🚨 PROBLEM 4: Race Condition on current Player Switch

current = (current==p1? p2:p1);

If two threads call play logic:

• Player may switch twice

• Wrong turn execution

• Inconsistent state

Fix: covered in our course.

🚨 PROBLEM 5: Logger Output Interleaving

cout << "[LOG] ...";

Two threads log simultaneously:

Output becomes:

[LOG] Alice m[LOG] Bob moved
oved

Fix: covered in our course.

🚨 PROBLEM 6: Deadlock Risk

If:

• Board mutex

• Strategy mutex

• Game mutex

Are locked in different order across threads deadlock.

Fix: covered in our course.

🚨 PROBLEM 7: Check-Then-Act Race

Example:

if(!placed)
    continue;

if(strategy->checkWin(...))

If two threads process same turn invalid.

Fix: covered in our course.

🚨 PROBLEM 8: AI Thread vs Human Thread

If AI runs in separate thread:

• Both may place move simultaneously

• Breaks turn logic

Solution: covered in our course.

🚨 PROBLEM 9: Memory Visibility Issue

Without synchronization:

Thread A updates board Thread B may not see updated state (CPU cache issue)

Solution: covered in our course.

🚨 PROBLEM 10: Builder Not Thread-Safe

If multiple threads call:

GameBuilder builder;
builder.setSize(3);

Shared builder instance race.

Fix: covered in our course.

A Rate Limiter system should:

• Limit requests per client/user

• Support multiple rate limiting algorithms

• Allow dynamic algorithm switching

• Support different limits per client

• Return Allow / Deny decision

• Track usage statistics

• Log rate limit violations

• Be extensible for distributed systems

📌 2. Non-Functional Requirements

• High performance (O(1) where possible)

• Extensible architecture

• Clean separation of concerns

• Algorithm pluggability

• Easy to test

📌 3. Supported Algorithms

We implement four major algorithms:

1 Fixed Window Counter

Idea: Allow N requests per time window.

Example:
Limit = 3 requests
Window = 10 seconds

After 3 requests deny until window resets.

Complexity

• Time: O(1)

• Space: O(n clients)

2 Sliding Window Log

Idea: Store timestamps of each request.

Before allowing:

• Remove old timestamps

• Check remaining count

Complexity

• Time: O(k) (k = requests in window)

• Space: O(n k)

3 Token Bucket

Idea:

• Tokens refill over time

• Each request consumes 1 token

• If no token deny

Complexity

• Time: O(1)

• Space: O(n)

4 Leaky Bucket

Idea:

• Requests enter queue

• Requests leak at constant rate

• If queue full deny

Complexity

• Time: O(1)

• Space: O(n k)

📌 4. Design Patterns Used

📌 5. Class Design

classDiagram
    class Observer {
        <<abstract>>
        +update(string message) void
    }
    class Logger {
        +update(string message) void
    }
    Observer <|-- Logger

    class RateLimiterConfig {
        +int limit
        +int windowSize
    }

    class RateLimiterConfigBuilder {
        -RateLimiterConfig config
        +setLimit(int) Builder
        +setWindowSize(int) Builder
        +build() RateLimiterConfig
    }
    RateLimiterConfigBuilder --> RateLimiterConfig : creates

    class BaseRateLimiter {
        <<abstract>>
        #RateLimiterConfig config
        +BaseRateLimiter(RateLimiterConfig cfg)
        +allowRequest(string id) bool
        +process(string id) bool
    }
    BaseRateLimiter *-- RateLimiterConfig : contains

    class FixedWindowLimiter {
        -Map_Counter counter
        +process(string id) bool
    }
    BaseRateLimiter <|-- FixedWindowLimiter

    class SlidingWindowLimiter {
        -Map_Logs logs
        +process(string id) bool
    }
    BaseRateLimiter <|-- SlidingWindowLimiter

    class TokenBucketLimiter {
        -Map_Buckets buckets
        +process(string id) bool
    }
    BaseRateLimiter <|-- TokenBucketLimiter

    class LeakyBucketLimiter {
        -Map_Buckets buckets
        +process(string id) bool
    }
    BaseRateLimiter <|-- LeakyBucketLimiter

    class RateLimiterFactory {
        +createLimiter(string type, Config cfg) BaseLimiter
    }
    RateLimiterFactory --> BaseRateLimiter : creates

    class RateLimiterDecorator {
        #BaseLimiter limiter
        +RateLimiterDecorator(BaseLimiter l)
    }
    BaseRateLimiter <|-- RateLimiterDecorator
    RateLimiterDecorator o-- BaseRateLimiter : decorates

    class LoggingDecorator {
        -Observer observer
        +LoggingDecorator(BaseLimiter l, Observer obs)
        +process(string id) bool
    }
    RateLimiterDecorator <|-- LoggingDecorator
    LoggingDecorator --> Observer : notifies

    class ClientRepository {
        -Map_Clients clients
        +addClient(string id) void
        +exists(string id) bool
    }

    class Command {
        <<abstract>>
        +execute() void
    }
    class RequestCommand {
        -BaseLimiter limiter
        -string id
        +RequestCommand(BaseLimiter l, string id)
        +execute() void
    }
    Command <|-- RequestCommand
    RequestCommand --> BaseRateLimiter : uses

    class RateLimiterManager {
        -BaseLimiter limiter
        -RateLimiterManager()
        +getInstance() Manager
        +setLimiter(BaseLimiter l) void
        +getLimiter() BaseLimiter
    }
    RateLimiterManager o-- BaseRateLimiter : holds

📌 6. Complete C++ Implementation (Single Threaded)

This is intentionally single-threaded for machine coding clarity.

🔹 1. Observer Pattern (Logger)

class Observer {
public:
    virtual void update(string message) = 0;
    virtual ~Observer() {}
};

class Logger : public Observer {
public:
    void update(string message) override {
        cout << "[LOG]: " << message << endl;
    }
};

🔹 2. Builder Pattern (Configuration)

class RateLimiterConfig {
public:
    int limit;
    int windowSize;
};

class RateLimiterConfigBuilder {
private:
    RateLimiterConfig config;

public:
    RateLimiterConfigBuilder& setLimit(int l) {
        config.limit = l;
        return *this;
    }

    RateLimiterConfigBuilder& setWindowSize(int w) {
        config.windowSize = w;
        return *this;
    }

    RateLimiterConfig build() {
        return config;
    }
};

🔹 3. Template Method Pattern

class BaseRateLimiter {
protected:
    RateLimiterConfig config;

public:
    BaseRateLimiter(RateLimiterConfig cfg) : config(cfg) {}

    bool allowRequest(string clientId) {
        return process(clientId);
    }

    virtual bool process(string clientId) = 0;
    virtual ~BaseRateLimiter() {}
};

📌 7. Strategy Pattern (All Algorithms)

🔹 Fixed Window

class FixedWindowLimiter : public BaseRateLimiter {
private:
    unordered_map<string, pair<int, time_t>> counter;

public:
    FixedWindowLimiter(RateLimiterConfig cfg)
        : BaseRateLimiter(cfg) {}

    bool process(string clientId) override {
        time_t now = time(nullptr);

        if(counter[clientId].second + config.windowSize <= now) {
            counter[clientId] = {1, now};
            return true;
        }

        if(counter[clientId].first < config.limit) {
            counter[clientId].first++;
            return true;
        }

        return false;
    }
};

🔹 Sliding Window

class SlidingWindowLimiter : public BaseRateLimiter {
private:
    unordered_map<string, vector<time_t>> logs;

public:
    SlidingWindowLimiter(RateLimiterConfig cfg)
        : BaseRateLimiter(cfg) {}

    bool process(string clientId) override {
        time_t now = time(nullptr);
        auto& timestamps = logs[clientId];

        timestamps.erase(remove_if(timestamps.begin(), timestamps.end(),
            [&](time_t t) { return t <= now - config.windowSize; }),
            timestamps.end());

        if(timestamps.size() < config.limit) {
            timestamps.push_back(now);
            return true;
        }

        return false;
    }
};

🔹 Token Bucket

class TokenBucketLimiter : public BaseRateLimiter {
private:
    struct Bucket {
        int tokens = 0;
        time_t lastRefill = 0;
    };

    unordered_map<string, Bucket> buckets;

public:
    TokenBucketLimiter(RateLimiterConfig cfg)
        : BaseRateLimiter(cfg) {}

    bool process(string clientId) override {
        time_t now = time(nullptr);
        auto& bucket = buckets[clientId];

        if(bucket.tokens == 0) {
            bucket.tokens = config.limit;
            bucket.lastRefill = now;
        }

        int refill = now - bucket.lastRefill;
        if(refill > 0) {
            bucket.tokens = min(config.limit, bucket.tokens + refill);
            bucket.lastRefill = now;
        }

        if(bucket.tokens > 0) {
            bucket.tokens--;
            return true;
        }

        return false;
    }
};

🔹 Leaky Bucket

class LeakyBucketLimiter : public BaseRateLimiter {
private:
    struct Bucket {
        queue<time_t> requests;
    };

    unordered_map<string, Bucket> buckets;

public:
    LeakyBucketLimiter(RateLimiterConfig cfg)
        : BaseRateLimiter(cfg) {}

    bool process(string clientId) override {
        time_t now = time(nullptr);
        auto& bucket = buckets[clientId];

        while(!bucket.requests.empty() &&
              bucket.requests.front() <= now - config.windowSize) {
            bucket.requests.pop();
        }

        if(bucket.requests.size() < config.limit) {
            bucket.requests.push(now);
            return true;
        }

        return false;
    }
};

📌 8. Factory Pattern

class RateLimiterFactory {
public:
    static shared_ptr<BaseRateLimiter> createLimiter(
        string type, RateLimiterConfig config) {

        if(type == "FIXED")
            return make_shared<FixedWindowLimiter>(config);
        if(type == "SLIDING")
            return make_shared<SlidingWindowLimiter>(config);
        if(type == "TOKEN")
            return make_shared<TokenBucketLimiter>(config);
        if(type == "LEAKY")
            return make_shared<LeakyBucketLimiter>(config);

        return nullptr;
    }
};

📌 9. Decorator Pattern (Logging)

class RateLimiterDecorator : public BaseRateLimiter {
protected:
    shared_ptr<BaseRateLimiter> limiter;

public:
    RateLimiterDecorator(shared_ptr<BaseRateLimiter> l)
        : BaseRateLimiter(l->config), limiter(l) {}
};

class LoggingDecorator : public RateLimiterDecorator {
private:
    Observer* observer;

public:
    LoggingDecorator(shared_ptr<BaseRateLimiter> l, Observer* obs)
        : RateLimiterDecorator(l), observer(obs) {}

    bool process(string clientId) override {
        bool allowed = limiter->allowRequest(clientId);

        if(!allowed)
            observer->update("Rate limit exceeded for: " + clientId);

        return allowed;
    }
};

📌 10. Repository Pattern

class ClientRepository {
private:
    unordered_map<string, int> clients;

public:
    void addClient(string id) {
        clients[id] = 1;
    }

    bool exists(string id) {
        return clients.count(id);
    }
};

📌 11. Command Pattern

class Command {
public:
    virtual void execute() = 0;
    virtual ~Command() {}
};

class RequestCommand : public Command {
private:
    shared_ptr<BaseRateLimiter> limiter;
    string clientId;

public:
    RequestCommand(shared_ptr<BaseRateLimiter> l, string id)
        : limiter(l), clientId(id) {}

    void execute() override {
        bool allowed = limiter->allowRequest(clientId);
        cout << "Request for " << clientId
             << (allowed ? " Allowed" : " Denied") << endl;
    }
};

📌 12. Singleton Manager

class RateLimiterManager {
private:
    shared_ptr<BaseRateLimiter> limiter;

    RateLimiterManager() {}

public:
    static RateLimiterManager& getInstance() {
        static RateLimiterManager instance;
        return instance;
    }

    void setLimiter(shared_ptr<BaseRateLimiter> l) {
        limiter = l;
    }

    shared_ptr<BaseRateLimiter> getLimiter() {
        return limiter;
    }
};

📌 13. Main Function

int main() {

    RateLimiterConfig config =
        RateLimiterConfigBuilder()
            .setLimit(3)
            .setWindowSize(10)
            .build();

    auto limiter = RateLimiterFactory::createLimiter("SLIDING", config);

    Logger logger;
    auto decoratedLimiter =
        make_shared<LoggingDecorator>(limiter, &logger);

    RateLimiterManager::getInstance().setLimiter(decoratedLimiter);

    string client = "clientA";

    for(int i = 0; i < 5; i++) {
        RequestCommand cmd(
            RateLimiterManager::getInstance().getLimiter(),
            client
        );
        cmd.execute();
    }

    return 0;
}

Complete running code

#include <iostream>
#include <unordered_map>
#include <queue>
#include <vector>
#include <memory>
#include <ctime>

using namespace std;

//////////////////////////////////////////////////////////////
// OBSERVER PATTERN
//////////////////////////////////////////////////////////////

class Observer {
public:
    virtual void update(string message) = 0;
    virtual ~Observer() {}
};

class Logger : public Observer {
public:
    void update(string message) override {
        cout << "[LOG]: " << message << endl;
    }
};

//////////////////////////////////////////////////////////////
// BUILDER PATTERN
//////////////////////////////////////////////////////////////

class RateLimiterConfig {
public:
    int limit;
    int windowSize;
};

class RateLimiterConfigBuilder {
private:
    RateLimiterConfig config;

public:
    RateLimiterConfigBuilder& setLimit(int l) {
        config.limit = l;
        return *this;
    }

    RateLimiterConfigBuilder& setWindowSize(int w) {
        config.windowSize = w;
        return *this;
    }

    RateLimiterConfig build() {
        return config;
    }
};

//////////////////////////////////////////////////////////////
// TEMPLATE METHOD PATTERN
//////////////////////////////////////////////////////////////

class BaseRateLimiter {
protected:
    RateLimiterConfig config;

public:
    BaseRateLimiter(RateLimiterConfig cfg) : config(cfg) {}

    bool allowRequest(string clientId) {
        return process(clientId);
    }

    virtual bool process(string clientId) = 0;
    virtual ~BaseRateLimiter() {}
};

//////////////////////////////////////////////////////////////
// STRATEGY PATTERN (Algorithms)
//////////////////////////////////////////////////////////////

class FixedWindowLimiter : public BaseRateLimiter {
private:
    unordered_map<string, pair<int, time_t>> counter;

public:
    FixedWindowLimiter(RateLimiterConfig cfg)
        : BaseRateLimiter(cfg) {}

    bool process(string clientId) override {
        time_t now = time(nullptr);

        if(counter[clientId].second + config.windowSize <= now) {
            counter[clientId] = {1, now};
            return true;
        }

        if(counter[clientId].first < config.limit) {
            counter[clientId].first++;
            return true;
        }

        return false;
    }
};

class SlidingWindowLimiter : public BaseRateLimiter {
private:
    unordered_map<string, vector<time_t>> logs;

public:
    SlidingWindowLimiter(RateLimiterConfig cfg)
        : BaseRateLimiter(cfg) {}

    bool process(string clientId) override {
        time_t now = time(nullptr);
        auto& timestamps = logs[clientId];

        timestamps.erase(remove_if(timestamps.begin(), timestamps.end(),
            [&](time_t t) { return t <= now - config.windowSize; }),
            timestamps.end());

        if(timestamps.size() < config.limit) {
            timestamps.push_back(now);
            return true;
        }

        return false;
    }
};

class TokenBucketLimiter : public BaseRateLimiter {
private:
    struct Bucket {
        int tokens;
        time_t lastRefill;
    };

    unordered_map<string, Bucket> buckets;

public:
    TokenBucketLimiter(RateLimiterConfig cfg)
        : BaseRateLimiter(cfg) {}

    bool process(string clientId) override {
        time_t now = time(nullptr);
        auto& bucket = buckets[clientId];

        if(bucket.tokens == 0) {
            bucket.tokens = config.limit;
            bucket.lastRefill = now;
        }

        int refill = (now - bucket.lastRefill);
        if(refill > 0) {
            bucket.tokens = min(config.limit, bucket.tokens + refill);
            bucket.lastRefill = now;
        }

        if(bucket.tokens > 0) {
            bucket.tokens--;
            return true;
        }

        return false;
    }
};

class LeakyBucketLimiter : public BaseRateLimiter {
private:
    struct Bucket {
        queue<time_t> requests;
    };

    unordered_map<string, Bucket> buckets;

public:
    LeakyBucketLimiter(RateLimiterConfig cfg)
        : BaseRateLimiter(cfg) {}

    bool process(string clientId) override {
        time_t now = time(nullptr);
        auto& bucket = buckets[clientId];

        while(!bucket.requests.empty() &&
              bucket.requests.front() <= now - config.windowSize) {
            bucket.requests.pop();
        }

        if(bucket.requests.size() < config.limit) {
            bucket.requests.push(now);
            return true;
        }

        return false;
    }
};

//////////////////////////////////////////////////////////////
// FACTORY METHOD
//////////////////////////////////////////////////////////////

class RateLimiterFactory {
public:
    static shared_ptr<BaseRateLimiter> createLimiter(
        string type, RateLimiterConfig config) {

        if(type == "FIXED")
            return make_shared<FixedWindowLimiter>(config);
        if(type == "SLIDING")
            return make_shared<SlidingWindowLimiter>(config);
        if(type == "TOKEN")
            return make_shared<TokenBucketLimiter>(config);
        if(type == "LEAKY")
            return make_shared<LeakyBucketLimiter>(config);

        return nullptr;
    }
};

//////////////////////////////////////////////////////////////
// DECORATOR PATTERN (Logging)
//////////////////////////////////////////////////////////////

class RateLimiterDecorator : public BaseRateLimiter {
protected:
    shared_ptr<BaseRateLimiter> limiter;

public:
    RateLimiterDecorator(shared_ptr<BaseRateLimiter> l)
        : BaseRateLimiter(l->config), limiter(l) {}
};

class LoggingDecorator : public RateLimiterDecorator {
private:
    Observer* observer;

public:
    LoggingDecorator(shared_ptr<BaseRateLimiter> l, Observer* obs)
        : RateLimiterDecorator(l), observer(obs) {}

    bool process(string clientId) override {
        bool allowed = limiter->allowRequest(clientId);

        if(!allowed)
            observer->update("Rate limit exceeded for: " + clientId);

        return allowed;
    }
};

//////////////////////////////////////////////////////////////
// REPOSITORY PATTERN
//////////////////////////////////////////////////////////////

class ClientRepository {
private:
    unordered_map<string, int> clients;

public:
    void addClient(string id) {
        clients[id] = 1;
    }

    bool exists(string id) {
        return clients.count(id);
    }
};

//////////////////////////////////////////////////////////////
// COMMAND PATTERN
//////////////////////////////////////////////////////////////

class Command {
public:
    virtual void execute() = 0;
    virtual ~Command() {}
};

class RequestCommand : public Command {
private:
    shared_ptr<BaseRateLimiter> limiter;
    string clientId;

public:
    RequestCommand(shared_ptr<BaseRateLimiter> l, string id)
        : limiter(l), clientId(id) {}

    void execute() override {
        bool allowed = limiter->allowRequest(clientId);
        cout << "Request for " << clientId
             << (allowed ? " Allowed" : " Denied") << endl;
    }
};

//////////////////////////////////////////////////////////////
// SINGLETON MANAGER
//////////////////////////////////////////////////////////////

class RateLimiterManager {
private:
    shared_ptr<BaseRateLimiter> limiter;

    RateLimiterManager() {}

public:
    static RateLimiterManager& getInstance() {
        static RateLimiterManager instance;
        return instance;
    }

    void setLimiter(shared_ptr<BaseRateLimiter> l) {
        limiter = l;
    }

    shared_ptr<BaseRateLimiter> getLimiter() {
        return limiter;
    }
};

//////////////////////////////////////////////////////////////
// MAIN
//////////////////////////////////////////////////////////////

int main() {

    RateLimiterConfig config =
        RateLimiterConfigBuilder()
            .setLimit(3)
            .setWindowSize(10)
            .build();

    auto limiter = RateLimiterFactory::createLimiter("SLIDING", config);

    Logger logger;
    auto decoratedLimiter =
        make_shared<LoggingDecorator>(limiter, &logger);

    RateLimiterManager::getInstance().setLimiter(decoratedLimiter);

    string client = "clientA";

    for(int i = 0; i < 5; i++) {
        RequestCommand cmd(
            RateLimiterManager::getInstance().getLimiter(),
            client
        );
        cmd.execute();
    }

    return 0;
}

📌 14. Complexity Summary

📌 15. Interview-Level Talking Points

Why Strategy? Switch algorithms dynamically

Why Template Method? Standardize request flow

Why Decorator? Add logging without modifying core

Why Builder? Clean configuration

Why Factory? Decouple creation

Why Singleton? Global configuration control

🚨 Multithreading Problems in the Above Rate Limiter Implementation

Our current implementation is single-threaded.

If multiple threads call:

allowRequest(clientId);

simultaneously the system becomes unsafe.

Below is a complete breakdown of all concurrency problems and their proper solutions.

🔴 PROBLEM 1: Data Race on unordered_map

Where?

In every algorithm:

unordered_map<string, ...> logs;
unordered_map<string, ...> counter;
unordered_map<string, Bucket> buckets;

Why Its Dangerous?

unordered_map is NOT thread-safe.

Two threads doing:

logs[clientId]

can:

• Corrupt internal bucket structure

• Cause undefined behavior

• Crash program

Solution : covered in our course

🔴 PROBLEM 2: Lost Update (Counter Increment Race)

In Fixed Window:

counter[clientId].first++;

Two threads:

Thread A reads 2 Thread B reads 2 Thread A writes 3 Thread B writes 3

Expected: 4 Actual: 3

Classic lost update problem.

Solution : covered in our course

🔴 PROBLEM 3: Check-Then-Act Race (Sliding Window)

if(timestamps.size() < config.limit) {
    timestamps.push_back(now);
}

Two threads:

Thread A checks size = 2 Thread B checks size = 2 Both push Limit = 3 Now size = 4

Solution : covered in our course

🔴 PROBLEM 4: Token Bucket Race

In Token Bucket:

bucket.tokens--;

Two threads:

• Both see tokens = 1

• Both decrement

• tokens becomes -1

Solution 4A: covered in our course

Solution 4B (Better): covered in our course

🔴 PROBLEM 5: Singleton Not Fully Safe (Configuration Change)

If one thread:

setLimiter(...)

While another thread:

getLimiter()

Race condition possible.

Solution: covered in our course

🔴 PROBLEM 6: Logging Race (Observer Pattern)

If multiple threads:

observer->update(...)

Output may interleave:

[LOG]: Rate limi[LOG]: Rate limit exceeded...

Solution: covered in our course

🔴 PROBLEM 7: Memory Reallocation Race (Vector Erase)

In Sliding Window:

timestamps.erase(...)

If two threads erase simultaneously:

• Iterator invalidation

• Memory corruption

Solution: covered in our course

🔴 PROBLEM 8: Global Lock Bottleneck

If we use:

std::mutex mtx;

One global lock only one request processed at a time.

Not scalable.

Solution: covered in our course

🔴 PROBLEM 9: Deadlock Risk

If:

• Manager lock

• Algorithm lock

• Logger lock

And locking order differs deadlock.

Solution: covered in our course

🔴 PROBLEM 10: Time Function Not Monotonic

time(nullptr)

If system clock changes limiter breaks.

Solution: covered in our course

For Java LLD, visit - https://www.lldcoding.com/design-lld-rate-limiter-machine-coding

A vending machine should support:

• Add products

• Add inventory (quantity)

• Insert money (multiple denominations)

• Select product

• Dispense product

• Return change

• Cancel transaction

• Handle insufficient balance

• Handle out-of-stock

• Maintain transaction states

• Support different pricing strategies

• Notify user for events

2 Core Entities

• Product

• InventorySlot

• VendingMachine

• Transaction

• Payment

• ChangeDispenser

• State

• PricingStrategy

3 Design Patterns Used

4 Algorithms Involved

1 Change Calculation (Greedy Algorithm)

Used to return minimum coins.

For each denomination (highest  lowest):
    count = remaining / denom
    remaining %= denom

2 Inventory Lookup (O(1))

Use:

unordered_map<string, InventorySlot>

3 State Transition Validation

Controlled transitions:

Idle  MoneyInserted  ProductSelected  Dispensing  Idle

4 Balance Validation

if insertedAmount >= productPrice

5 COMPLETE C++ IMPLEMENTATION

Single-threaded

#include <iostream>
#include <vector>
#include <memory>
#include <unordered_map>
#include <map>
#include <algorithm>

using namespace std;

//////////////////////////////////////////////////////////////
// ENUMS
//////////////////////////////////////////////////////////////

enum class Denomination { ONE=1, FIVE=5, TEN=10, TWENTY=20, FIFTY=50 };
enum class MachineStatus { IDLE, MONEY_INSERTED, PRODUCT_SELECTED, DISPENSING };

//////////////////////////////////////////////////////////////
// OBSERVER PATTERN
//////////////////////////////////////////////////////////////

class Observer {
public:
    virtual void update(const string& msg) = 0;
    virtual ~Observer() {}
};

class Display : public Observer {
public:
    void update(const string& msg) override {
        cout << "[Display]: " << msg << endl;
    }
};

//////////////////////////////////////////////////////////////
// PRODUCT
//////////////////////////////////////////////////////////////

class Product {
protected:
    string name;
    double basePrice;

public:
    Product(string n, double p) : name(n), basePrice(p) {}
    virtual ~Product() {}

    virtual string getName() { return name; }
    virtual double getPrice() { return basePrice; }
};

//////////////////////////////////////////////////////////////
// FACTORY METHOD
//////////////////////////////////////////////////////////////

class ProductFactory {
public:
    static shared_ptr<Product> createProduct(const string& type) {
        if(type == "Coke") return make_shared<Product>("Coke", 25);
        if(type == "Pepsi") return make_shared<Product>("Pepsi", 20);
        if(type == "Chips") return make_shared<Product>("Chips", 15);
        return nullptr;
    }
};

//////////////////////////////////////////////////////////////
// DECORATOR PATTERN (GiftWrap Add-on)
//////////////////////////////////////////////////////////////

class ProductDecorator : public Product {
protected:
    shared_ptr<Product> product;
public:
    ProductDecorator(shared_ptr<Product> p)
        : Product(p->getName(), p->getPrice()), product(p) {}
};

class GiftWrapDecorator : public ProductDecorator {
public:
    GiftWrapDecorator(shared_ptr<Product> p)
        : ProductDecorator(p) {}

    double getPrice() override {
        return product->getPrice() + 5;
    }

    string getName() override {
        return product->getName() + " + GiftWrap";
    }
};

//////////////////////////////////////////////////////////////
// STRATEGY PATTERN (Pricing)
//////////////////////////////////////////////////////////////

class PricingStrategy {
public:
    virtual double calculatePrice(shared_ptr<Product> product) = 0;
    virtual ~PricingStrategy() {}
};

class RegularPricing : public PricingStrategy {
public:
    double calculatePrice(shared_ptr<Product> product) override {
        return product->getPrice();
    }
};

class DiscountPricing : public PricingStrategy {
public:
    double calculatePrice(shared_ptr<Product> product) override {
        return product->getPrice() * 0.9;
    }
};

//////////////////////////////////////////////////////////////
// INVENTORY REPOSITORY
//////////////////////////////////////////////////////////////

class InventorySlot {
public:
    shared_ptr<Product> product;
    int quantity;

    InventorySlot(shared_ptr<Product> p, int q)
        : product(p), quantity(q) {}
};

class InventoryRepository {
private:
    unordered_map<string, InventorySlot> inventory;

public:
    void addProduct(shared_ptr<Product> product, int quantity) {
        inventory[product->getName()] = InventorySlot(product, quantity);
    }

    bool isAvailable(string name) {
        return inventory.count(name) && inventory[name].quantity > 0;
    }

    shared_ptr<Product> getProduct(string name) {
        return inventory[name].product;
    }

    void reduceStock(string name) {
        inventory[name].quantity--;
    }
};

//////////////////////////////////////////////////////////////
// BUILDER PATTERN (Receipt)
//////////////////////////////////////////////////////////////

class Receipt {
public:
    string productName;
    double amount;
};

class ReceiptBuilder {
private:
    Receipt receipt;

public:
    ReceiptBuilder& setProduct(string name) {
        receipt.productName = name;
        return *this;
    }

    ReceiptBuilder& setAmount(double amt) {
        receipt.amount = amt;
        return *this;
    }

    Receipt build() {
        return receipt;
    }
};

//////////////////////////////////////////////////////////////
// CHANGE DISPENSER (Greedy Algorithm)
//////////////////////////////////////////////////////////////

class ChangeDispenser {
private:
    vector<int> denominations = {50, 20, 10, 5, 1};

public:
    void dispenseChange(int amount) {
        cout << "Change returned: ";
        for(int d : denominations) {
            while(amount >= d) {
                cout << d << " ";
                amount -= d;
            }
        }
        cout << endl;
    }
};

//////////////////////////////////////////////////////////////
// STATE PATTERN
//////////////////////////////////////////////////////////////

class VendingMachine;

class State {
public:
    virtual void insertMoney(VendingMachine*, int) {}
    virtual void selectProduct(VendingMachine*, string) {}
    virtual void dispense(VendingMachine*) {}
    virtual void cancel(VendingMachine*) {}
    virtual ~State() {}
};

//////////////////////////////////////////////////////////////
// COMMAND PATTERN
//////////////////////////////////////////////////////////////

class Command {
public:
    virtual void execute() = 0;
    virtual ~Command() {}
};

//////////////////////////////////////////////////////////////
// VENDING MACHINE (Singleton)
//////////////////////////////////////////////////////////////

class VendingMachine {
private:
    State* currentState;
    InventoryRepository inventory;
    vector<Observer*> observers;
    ChangeDispenser changeDispenser;
    shared_ptr<PricingStrategy> pricingStrategy;

    int insertedAmount;
    string selectedProduct;

    VendingMachine() {
        insertedAmount = 0;
        pricingStrategy = make_shared<RegularPricing>();
    }

public:
    static VendingMachine& getInstance() {
        static VendingMachine instance;
        return instance;
    }

    void setState(State* state) { currentState = state; }

    void attach(Observer* obs) { observers.push_back(obs); }

    void notify(string msg) {
        for(auto obs : observers)
            obs->update(msg);
    }

    void addProduct(shared_ptr<Product> product, int quantity) {
        inventory.addProduct(product, quantity);
    }

    void insertMoney(int amount) {
        insertedAmount += amount;
        notify("Money Inserted: " + to_string(amount));
    }

    void selectProduct(string name) {
        if(!inventory.isAvailable(name)) {
            notify("Product not available");
            return;
        }
        selectedProduct = name;
        notify("Product Selected: " + name);
    }

    void dispenseProduct() {
        auto product = inventory.getProduct(selectedProduct);
        double price = pricingStrategy->calculatePrice(product);

        if(insertedAmount < price) {
            notify("Insufficient Balance");
            return;
        }

        inventory.reduceStock(selectedProduct);
        insertedAmount -= price;

        notify("Dispensing " + selectedProduct);

        changeDispenser.dispenseChange(insertedAmount);
        insertedAmount = 0;

        Receipt receipt = ReceiptBuilder()
            .setProduct(selectedProduct)
            .setAmount(price)
            .build();

        cout << "Receipt: " << receipt.productName 
             << " | Amount: " << receipt.amount << endl;
    }
};

//////////////////////////////////////////////////////////////
// MAIN
//////////////////////////////////////////////////////////////

int main() {

    VendingMachine& machine = VendingMachine::getInstance();

    Display display;
    machine.attach(&display);

    auto coke = ProductFactory::createProduct("Coke");
    machine.addProduct(coke, 5);

    machine.insertMoney(50);
    machine.selectProduct("Coke");
    machine.dispenseProduct();

    return 0;
}

6 Complexity Analysis

7 Interview Discussion Points

If interviewer asks:

Why State Pattern? Prevent invalid transitions.

Why Strategy? Allow flexible pricing (discount, surge, membership).

Why Decorator? Add-ons dynamically.

Why Builder? Receipt construction cleanly.

Why Repository? Decouple storage.

Why Singleton? Only one machine instance.

🚨 MULTI-THREADING PROBLEMS IN this DESIGN

1 Race Condition on insertedAmount

🔴 Problem

insertedAmount += amount;

If 2 threads call:

insertMoney(50)
insertMoney(20)

Possible interleaving:

Thread A reads 0 Thread B reads 0 Thread A writes 50 Thread B writes 20

Final amount = 20 (lost update)

This is a classic data race.

Solution: covered in our course.

2 Race Condition on Inventory

🔴 Problem

if(inventory.isAvailable(name))
inventory.reduceStock(name);

Two threads:

Thread A sees quantity = 1 Thread B sees quantity = 1 Both reduce Quantity becomes -1

Overselling.

Solution: : covered in our course.

3 Race Condition on selectedProduct

🔴 Problem

selectedProduct is shared global state.

If:

Thread A selects Coke Thread B selects Pepsi

Thread A dispenses might dispense Pepsi

Shared mutable state = broken machine.

Solution: : covered in our course.

4 Singleton Not Thread-Safe (Initialization)

C++11 static local is thread-safe.

But if using manual singleton:

static VendingMachine* instance;

Two threads double creation.

Solution: covered in our course.

5 Change Dispenser Race Condition

If two threads:

dispenseChange(amount);

Outputs interleaving messy logs.

Solution: covered in our course.

6 Observer List Race Condition

vector<Observer*> observers;

If:

Thread A attaches observer Thread B notifies

Possible iterator invalidation.

Solution: covered in our course.

7 Deadlock Risk

If:

• Inventory locks

• Machine locks

• ChangeDispenser locks

And locking order differs DEADLOCK.

Solution: covered in our course.

8 Check-Then-Act Race

if(insertedAmount >= price)

Thread A checks Thread B reduces insertedAmount Thread A continues

Incorrect dispense.

Solution: covered in our course.

9 Performance Issue: Global Lock Bottleneck

If we lock entire machine:

Only 1 user can operate at a time.

Not scalable.

Solution: covered in our course.

🔟 Starvation Risk

If using mutex unfairly one thread may starve.

Solution: covered in our course.

A hotel system should support:

• Add hotel rooms

• Search rooms (by type, price, availability)

• Book room

• Cancel booking

• Check-in

• Check-out

• Generate bill

• Payment processing

• Room pricing strategy

• Different room types (Single, Double, Suite)

2 Core Entities

• Room

• Guest

• Booking

• Payment

• Invoice

• Hotel

• Pricing Strategy

• Notification Service

3 Design Patterns Used (With Reason)

4 Algorithms Used

1. Room Allocation Algorithm

• Linear scan for available rooms

• Can be upgraded to priority queue

2. Date Overlap Detection

Overlap if:
!(end1 <= start2 || end2 <= start1)

3. Billing Calculation

Total = BasePrice + Services - Discounts

4. Search Algorithm

• Filter by type

• Filter by price range

• Check availability

5 COMPLETE C++

#include <iostream>
#include <vector>
#include <string>
#include <memory>
#include <map>
#include <algorithm>

using namespace std;

///////////////////////////////////////////////////////////
// ENUMS
///////////////////////////////////////////////////////////

enum class RoomType { SINGLE, DOUBLE, SUITE };
enum class BookingStatus { CREATED, CONFIRMED, CHECKED_IN, COMPLETED, CANCELLED };

///////////////////////////////////////////////////////////
// STRATEGY PATTERN - Pricing Strategy
///////////////////////////////////////////////////////////

class PricingStrategy {
public:
    virtual double calculatePrice(double basePrice, int nights) = 0;
    virtual ~PricingStrategy() {}
};

class RegularPricing : public PricingStrategy {
public:
    double calculatePrice(double basePrice, int nights) override {
        return basePrice * nights;
    }
};

class WeekendPricing : public PricingStrategy {
public:
    double calculatePrice(double basePrice, int nights) override {
        return basePrice * nights * 1.2; // 20% increase
    }
};

///////////////////////////////////////////////////////////
// OBSERVER PATTERN
///////////////////////////////////////////////////////////

class Observer {
public:
    virtual void update(string message) = 0;
};

class Guest : public Observer {
private:
    string name;
public:
    Guest(string name) : name(name) {}

    void update(string message) override {
        cout << "Notification for " << name << ": " << message << endl;
    }

    string getName() { return name; }
};

///////////////////////////////////////////////////////////
// ROOM CLASS
///////////////////////////////////////////////////////////

class Room {
protected:
    int roomNumber;
    RoomType type;
    double basePrice;
    bool available;

public:
    Room(int number, RoomType t, double price)
        : roomNumber(number), type(t), basePrice(price), available(true) {}

    virtual ~Room() {}

    int getRoomNumber() { return roomNumber; }
    RoomType getType() { return type; }
    double getBasePrice() { return basePrice; }
    bool isAvailable() { return available; }

    void setAvailability(bool status) { available = status; }
};

///////////////////////////////////////////////////////////
// FACTORY METHOD PATTERN
///////////////////////////////////////////////////////////

class RoomFactory {
public:
    static shared_ptr<Room> createRoom(RoomType type, int number) {
        switch(type) {
            case RoomType::SINGLE:
                return make_shared<Room>(number, type, 100);
            case RoomType::DOUBLE:
                return make_shared<Room>(number, type, 200);
            case RoomType::SUITE:
                return make_shared<Room>(number, type, 500);
        }
        return nullptr;
    }
};

///////////////////////////////////////////////////////////
// STATE PATTERN
///////////////////////////////////////////////////////////

class Booking;

class BookingState {
public:
    virtual void next(Booking* booking) = 0;
    virtual string getStatus() = 0;
};

///////////////////////////////////////////////////////////
// DECORATOR PATTERN - Extra Services
///////////////////////////////////////////////////////////

class RoomService {
public:
    virtual double cost() = 0;
    virtual string description() = 0;
    virtual ~RoomService() {}
};

class BasicRoomService : public RoomService {
public:
    double cost() override { return 0; }
    string description() override { return "Basic Room"; }
};

class SpaDecorator : public RoomService {
private:
    shared_ptr<RoomService> service;
public:
    SpaDecorator(shared_ptr<RoomService> s) : service(s) {}

    double cost() override {
        return service->cost() + 50;
    }

    string description() override {
        return service->description() + " + Spa";
    }
};

///////////////////////////////////////////////////////////
// BOOKING CLASS
///////////////////////////////////////////////////////////

class Booking {
private:
    int bookingId;
    shared_ptr<Room> room;
    shared_ptr<Guest> guest;
    int nights;
    shared_ptr<PricingStrategy> pricingStrategy;
    shared_ptr<RoomService> roomService;

public:
    Booking(int id, shared_ptr<Room> r, shared_ptr<Guest> g, int nights,
            shared_ptr<PricingStrategy> strategy)
        : bookingId(id), room(r), guest(g), nights(nights),
          pricingStrategy(strategy) {
        roomService = make_shared<BasicRoomService>();
    }

    void addService(shared_ptr<RoomService> service) {
        roomService = service;
    }

    double calculateBill() {
        double base = pricingStrategy->calculatePrice(room->getBasePrice(), nights);
        return base + roomService->cost();
    }

    void confirm() {
        room->setAvailability(false);
        guest->update("Booking Confirmed!");
    }

    void cancel() {
        room->setAvailability(true);
        guest->update("Booking Cancelled!");
    }

    int getId() { return bookingId; }
};

///////////////////////////////////////////////////////////
// BUILDER PATTERN - Invoice
///////////////////////////////////////////////////////////

class Invoice {
public:
    double amount;
    string details;
};

class InvoiceBuilder {
private:
    Invoice invoice;
public:
    InvoiceBuilder& setAmount(double amt) {
        invoice.amount = amt;
        return *this;
    }

    InvoiceBuilder& setDetails(string det) {
        invoice.details = det;
        return *this;
    }

    Invoice build() {
        return invoice;
    }
};

///////////////////////////////////////////////////////////
// REPOSITORY PATTERN
///////////////////////////////////////////////////////////

class BookingRepository {
private:
    map<int, shared_ptr<Booking>> bookings;

public:
    void save(shared_ptr<Booking> booking) {
        bookings[booking->getId()] = booking;
    }

    shared_ptr<Booking> find(int id) {
        return bookings[id];
    }
};

///////////////////////////////////////////////////////////
// SINGLETON - HOTEL SYSTEM
///////////////////////////////////////////////////////////

class HotelSystem {
private:
    vector<shared_ptr<Room>> rooms;
    BookingRepository bookingRepo;

    HotelSystem() {}

public:
    static HotelSystem& getInstance() {
        static HotelSystem instance;
        return instance;
    }

    void addRoom(RoomType type, int number) {
        rooms.push_back(RoomFactory::createRoom(type, number));
    }

    shared_ptr<Room> searchAvailable(RoomType type) {
        for (auto& room : rooms) {
            if (room->getType() == type && room->isAvailable())
                return room;
        }
        return nullptr;
    }

    shared_ptr<Booking> bookRoom(int bookingId, shared_ptr<Guest> guest,
                                 RoomType type, int nights) {

        auto room = searchAvailable(type);
        if (!room) {
            cout << "No room available\n";
            return nullptr;
        }

        auto strategy = make_shared<RegularPricing>();
        auto booking = make_shared<Booking>(bookingId, room, guest, nights, strategy);

        booking->confirm();
        bookingRepo.save(booking);

        return booking;
    }

    void checkout(int bookingId) {
        auto booking = bookingRepo.find(bookingId);
        if (!booking) return;

        double bill = booking->calculateBill();

        Invoice invoice = InvoiceBuilder()
                .setAmount(bill)
                .setDetails("Hotel Stay Charges")
                .build();

        cout << "Invoice Generated: " << invoice.amount << endl;
    }
};

///////////////////////////////////////////////////////////
// MAIN
///////////////////////////////////////////////////////////

int main() {

    HotelSystem& system = HotelSystem::getInstance();

    system.addRoom(RoomType::SINGLE, 101);
    system.addRoom(RoomType::DOUBLE, 102);

    auto guest = make_shared<Guest>("John");

    auto booking = system.bookRoom(1, guest, RoomType::SINGLE, 3);

    if (booking) {
        auto service = make_shared<SpaDecorator>(
                make_shared<BasicRoomService>());
        booking->addService(service);

        system.checkout(1);
    }

    return 0;
}

6 Complexity Analysis

7 How to Improve for Production?

• Use priority queue for optimized allocation

• Use interval tree for date-based booking

• Add payment gateway integration

• Make it thread-safe

• Replace in-memory repo with DB

8 Interview Discussion Points

If asked:

• Why Strategy? Pricing flexibility

• Why State? Booking lifecycle control

• Why Decorator? Add services dynamically

• Why Repository? Abstraction from storage

• Why Singleton? Centralized management

• Why Factory? Room object creation abstraction

Problems in this implementation:

We built a single-threaded Hotel Management System. Now lets analyze:

What problems still exist in a this single-threaded design? Why is single-threaded not enough in real systems? How do we fix each issue?

🚨 1 Double Booking Problem (Logical Race Condition)

🔴 Problem

Even in single-threaded systems, you can still have logical race conditions.

Example:

1. Search room Available

2. Before booking finalizes, another booking call happens

3. Both see room as available

4. Double booking happens

This is not thread-race. This is check-then-act problem.

Why It Happens

Because:

searchAvailable()
confirm()

are separate operations.

Solution

Covered in our C++ course

🚨 2 No Date Handling Overlapping Bookings

🔴 Problem

Current system only checks:

room->isAvailable()

But hotels operate on date ranges.

Without date validation:

• Guest A: Jan 13

• Guest B: Jan 25 System allows both.

Why It Happens

We dont track booking intervals.

Solution:

Covered in our C++ course

🚨 3 Poor Room Search Performance (O(n))

🔴 Problem

Search scans all rooms:

for (auto& room : rooms)

If hotel has 10,000 rooms slow.

Why It Happens

We use linear search.

Solution:

Covered in our C++ course

🚨 4 No Payment Failure Handling

🔴 Problem

Checkout directly generates invoice.

But:

• What if payment fails?

• What if partial payment?

System currently assumes success.

Solution

Covered in our C++ course

🚨 5 No Booking State Validation

🔴 Problem

User can:

• Cancel after checkout

• Check-in twice

• Checkout before check-in

No lifecycle enforcement.

Solution: Proper State Pattern

Covered in our C++ course

🚨 6 Memory Leak Risk

🔴 Problem

If using raw pointers:

• Memory leaks

• Dangling pointers

Solution

Covered in our C++ course

🚨 7 No Persistence (Data Loss)

🔴 Problem

System is in-memory.

If server restarts all data lost.

Solution:

Covered in our C++ course

🚨 8 No Scalability

🔴 Problem

Single-threaded means:

• One request at a time

• No parallel bookings

• Slow during peak traffic

Solution

Covered in our C++ course

🚨 9 No Audit Logging

🔴 Problem

System does not track:

• Who booked

• Who cancelled

• When changed

Solution

Covered in our C++ course

Core Requirements

• One user one reaction per entity

• Reaction can change over time

• Extremely write-heavy

• Reads need fast aggregated counts

• Prevent duplicate reactions

This is not a simple likes table problem.

Solutions

1. Naive Design (Why It Fails)

Code given in github repo.

Problems

• No uniqueness duplicate reactions

• COUNT(*) on every read

• Full table scans under load

• Read amplification explodes

Works at 10 users. Dies at 10 million.

2. Optimized Data Model (Correct Foundation)

We separate concerns:

• Truth (who reacted)

• Speed (aggregated counts)

2.1 Core Reaction Table (Uniqueness + Truth)

Code given in github repo.

Why This Works

• Enforces 1 reaction per user per entity

• Reaction change = UPDATE, not new row

• Write cost is predictable

2.2 Pre-Aggregated Counters (Read Optimization)

Code given in github repo.

Why This Exists

• Reads are O(1)

• No GROUP BY

• No scanning reaction table

🔄 3. Handling Reaction Updates (Critical Part)

Scenario

User changes reaction:

LIKE  LOVE

Correct Flow

1. Read existing reaction

2. Decrement old counter

3. Increment new counter

4. Update reaction row

5. All inside one transaction

Why Atomicity Matters

• Prevents counter drift

• Guarantees consistency

🔁 Alternative Solutions

1 Event-Driven Counters (Async Aggregation)

Idea

• Writes go only to the Reaction table

• Counters updated asynchronously via events

Flow

1. User reacts

2. Persist reaction

3. Emit event (reaction_added / reaction_changed)

4. Consumer updates counters

Why Use This

Absorbs write spikes
Decouples write path
Great for huge scale

Tradeoffs

Eventual consistency
Needs reconciliation

2 Log-Structured / Append-Only Reactions

Idea

• Never update reactions

• Append every change

• Compute latest reaction via compaction

(user=1, post=7, LIKE)
(user=1, post=7, LOVE)

Why Use This

Perfect audit trail
High write throughput
Works well with Kafka

Tradeoffs

Read complexity
Needs background jobs

3 Redis-Only Atomic Counters + Sets

Idea

Use Redis as primary reaction store.

SET post:7:users
HINCRBY post:7:counts LIKE 1

Flow

• SADD enforces uniqueness

• HINCRBY updates counters atomically

Why Use This

Extremely fast
Simple logic
Atomic operations

Tradeoffs

Memory expensive
Persistence risk
Not ideal as source of truth

4 Bitmaps for Binary Reactions (Like / Unlike)

Idea

• If reaction is binary, use bitmap

BITSET post:7 12345 1

Why Use This

Ultra memory efficient
Fast counts

Tradeoffs

Not for multiple reaction types
User ID must be dense

5 Fanout-on-Write (Precompute Everything)

Idea

• Write path updates every read model

• Reads become trivial

Why Use This

Zero read computation
Best for read-heavy apps

Tradeoffs

Massive write amplification
Complex rollback

6 Materialized Views (DB-Native)

Idea

Let DB maintain aggregates.

CREATE MATERIALIZED VIEW reaction_counts AS
SELECT entity_id, reaction_type, COUNT(*)
FROM Reaction
GROUP BY entity_id, reaction_type;

Why Use This

Simple mental model
DB-managed

Tradeoffs

Refresh cost
Limited scalability

7 CRDT-Based Counters (Distributed Systems)

Idea

Use conflict-free replicated data types

• Each node increments locally

• Eventually converge

Code given in github repo.

Why Use This

Multi-region
Offline writes

Tradeoffs

Approximate
Complex reasoning

🧠 How to Choose (Decision Table)

All code given here - github repo.

Indexes dont make systems faster
they shift cost from reads to writes, memory, and latency tails.

🧠 The Illusion

CREATE INDEX idx_user_email ON users(email);

Looks harmless.
But this single line changes your entire system behavior.

🧩 Cost #1 Write Amplification

What Actually Happens on INSERT

INSERT INTO users (id, email, name) VALUES (...);

This causes:

1. Write to base table

2. Write to index B-Tree

3. Possible page split

4. WAL / redo log update

🧠 Key Point

1 logical write multiple physical writes

🧩 Cost #2 Slower Writes (Lock Contention)

Indexes increase lock scope.

UPDATE users SET email = 'x' WHERE id = 42;

Locks:

• Row lock (table)

• Index node lock

• Possibly parent nodes

Effect

• Higher contention

• Worse under high concurrency

🧩 Cost #3 Memory Pressure (Cache Pollution)

Indexes consume RAM aggressively.

What lives in memory

• Hot index pages

• Root & intermediate B-tree nodes

🧠 Result

Indexes can evict actual data, hurting cache hit rate.

🧩 Cost #4 Read Amplification Still Exists

Indexes dont always mean 1 read.

Example:

SELECT * FROM orders WHERE user_id = 42;

Execution:

1. Read index page

2. Read table page(s)

Index scan + table lookup = 2 I/O paths

🧩 Cost #5 Index Maintenance (Deletes & Updates)

Deletes dont free space immediately.

Problems:

• Fragmentation

• Page splits

• Rebalancing

• Vacuum / compaction overhead

Result

• Background CPU

• Unpredictable latency spikes

🧩 Cost #6 Indexes Hurt Write-Heavy Systems

Example: Like Counter

UPDATE posts SET likes = likes + 1 WHERE id = 7;

With index on likes:

• Every increment updates index order

• Constant tree rebalancing

Better

• No index

• Or async aggregation

🧠 When Indexes Make Things Worse

Example of a Bad Index

CREATE INDEX idx_gender ON users(gender);

Why bad?

• Low cardinality

  • What is cardinality ? will be explained in upcoming blog.

• Poor selectivity

• Index scan almost as big as table scan

When Indexes Are Worth It

Covering Index (The Only Free-ish One)

CREATE INDEX idx_user_email_name
ON users(email, name);

Query:

SELECT name FROM users WHERE email = ?;

No table lookup
Reduced read amplification

🔥 How This Connects to Previous Blogs

• Read Amplification indexes dont eliminate it

• Write Amplification indexes multiply it

• Hot Keys hot index pages become bottlenecks

• P99 latency index rebalancing spikes

Youre building a live podcast platform where:

• A host starts a live podcast session.

• Multiple guests are invited to join.

• The podcast must not start until all required guests have joined.

• Guests may join at different times.

• Everything happens concurrently (over the network, different threads).

📌 What Exactly Is the Problem?

We have dependencies between tasks:

• Each guest joining is an independent task.

• The host starting the podcast depends on all guests being present.

👉 This creates a synchronization problem:

One thread must wait until several other threads finish their work.

🧩 Mapping to Concurrency Concepts

🕒 Timeline Example

Imagine:

• Podcast needs 3 guests.

• Guests join at different times.

Time 
Guest 1 joins 
Guest 2 joins     
Guest 3 joins 
                              
                 🎤 Podcast Starts

The host cannot start early, even if:

• 1 guest joins

• 2 guests join

The host must wait for all 3.

🚨 Why This Is a Concurrency Problem

Naive Thinking (Wrong)

Just start the podcast when guests arrive.

Problems:

• Host might start before everyone joins.

• Host might check are guests ready? while guests are still joining.

• Leads to race conditions:

  • Host checks sees only 2 guests waits

  • Guest 3 joins immediately after host never notices

Core Challenges

1. Ordering

   • Guests can join in any order.

2. Timing

   • Guests join at unpredictable times.

3. Coordination

   • Host must wait, but not forever.

4. Correctness

   • Podcast must start exactly once.

5. Scalability

   • Works for 2 guests, 10 guests, or 100 guests.

🧠 What Makes This Problem Special?

This is not about sharing data (like counters or money).
This is about waiting for conditions.

It belongs to a special class of concurrency problems:

🔹 Wait until N things are done

Examples:

• App startup waits for DB + Cache + Config

• Game waits for all players to be ready

• Deployment waits for all services to be healthy

• Podcast waits for all guests to join 🎤

🧪 Key Question the System Must Answer

How does one thread know that all other threads are done?

Thats the heart of the problem.

Solutions

1. Naive Solution (Looks Correct, Actually Broken)

🧠 Naive Idea

• Keep a counter of guests who have joined.

• Host checks the counter.

• If count == required guests start podcast.

Naive Code (Conceptual)

class Podcast {
    int requiredGuests = 3;
    int joinedGuests = 0;

    void guestJoins() {
        joinedGuests++;
        System.out.println("Guest joined. Total = " + joinedGuests);
    }

    void hostStarts() {
        while (joinedGuests < requiredGuests) {
            // wait
        }
        System.out.println("🎤 Podcast started!");
    }
}

Why This Fails (Concurrency Problems)

🚨 Problem 1: Busy Waiting (CPU Waste)

• Host thread spins endlessly checking the condition.

• Wastes CPU cycles.

• Scales terribly.

🚨 Problem 2: Visibility Problem

Even worse this may never work.

Why?

• joinedGuests is not volatile

• Host thread may never see updates from guest threads.

📌 Host might loop forever, even after all guests join.

🚨 Problem 3: Race Condition

Two guests join at the same time:

Thread A reads joinedGuests = 1
Thread B reads joinedGuests = 1
Thread A writes joinedGuests = 2
Thread B writes joinedGuests = 2  

One join is lost.

🚨 Problem 4: Podcast May Start Multiple Times

If multiple host threads exist:

• All see joinedGuests == requiredGuests

• All start the podcast

💥 Multiple starts = disaster.

First Fix Attempt Add synchronized

Improved but Still Ugly

class Podcast {
    int requiredGuests = 3;
    int joinedGuests = 0;

    synchronized void guestJoins() {
        joinedGuests++;
        System.out.println("Guest joined. Total = " + joinedGuests);
    }

    synchronized void hostStarts() {
        while (joinedGuests < requiredGuests) {
            // still waiting
        }
        System.out.println("🎤 Podcast started!");
    }
}

Why This Still Fails

🚨 Problem 1: Host Holds the Lock

• Host enters hostStarts() and holds the lock.

• Guests can never enter guestJoins().

• Deadlock-like behavior.

🚨 Problem 2: Still Busy Waiting

• CPU burn continues.

• No proper waiting mechanism.

Realization (Key Insight)

We dont want:

• Polling

• Spinning

• Manual checking

We want:

Host sleeps until the last guest arrives, then wakes up exactly once.

This is a coordination problem, not a data-sharing problem.

Correct Mental Model

• Each guest says:
  Im ready.

• Host says:
  Wake me up when everyone is ready.

This maps perfectly to:

🧰 CountDownLatch

Correct Solution

Already covered in our premium course.

1. There are N rooms.

2. We are given a stream of meeting requests (start time, end time, capacity).

3. We have to assign a room to the meeting if available, considering:

   • The room must be free during the requested time.

   • The room must have at least the required capacity.

4. We must minimize spillage of free time (i.e., use the room that has the least free time that can accommodate the meeting).

5. We have to store audit logs for each room (when a meeting is scheduled, etc.) and delete audit logs after X days.

Additional considerations:

• Concurrency: multiple requests may come in simultaneously.

Solution/Approaches

Core LLD Components

1. Room Management

   1.  public class Room {
           private final String roomId;
           private final int capacity;
           private final NavigableMap<LocalDateTime, Interval> bookings; // TreeMap for sorted intervals
           private final ReentrantReadWriteLock rwLock;
      
           public Room(String roomId, int capacity) {
               this.roomId = roomId;
               this.capacity = capacity;
               this.bookings = new TreeMap<>();
               this.rwLock = new ReentrantReadWriteLock(true); // Fair lock
           }
      
           public boolean isAvailable(Interval requested) {
               rwLock.readLock().lock();
               try {
                   // Check using interval tree or binary search
                   Entry<LocalDateTime, Interval> floor = bookings.floorEntry(requested.getStart());
                   Entry<LocalDateTime, Interval> ceiling = bookings.ceilingEntry(requested.getStart());
      
                   return !conflictsWith(floor, requested) && !conflictsWith(ceiling, requested);
               } finally {
                   rwLock.readLock().unlock();
               }
           }
      
           private boolean conflictsWith(Entry<LocalDateTime, Interval> existing, Interval requested) {
               return existing != null && existing.getValue().overlaps(requested);
           }
       }
      

2. Interval Management

   1.  public class Interval implements Comparable<Interval> {
           private final LocalDateTime start;
           private final LocalDateTime end;
      
           public boolean overlaps(Interval other) {
               return !(this.end.isBefore(other.start) || this.start.isAfter(other.end));
           }
      
           // Calculate spillage when this interval is inserted into existing intervals
           public Duration calculateSpillage(List<Interval> existingIntervals) {
               List<Interval> merged = new ArrayList<>(existingIntervals);
               merged.add(this);
               Collections.sort(merged);
      
               Duration spillage = Duration.ZERO;
               for (int i = 0; i < merged.size() - 1; i++) {
                   Duration gap = Duration.between(merged.get(i).getEnd(), merged.get(i + 1).getStart());
                   if (!gap.isNegative() && !gap.isZero()) {
                       spillage = spillage.plus(gap);
                   }
               }
               return spillage;
           }
       }
      

3. Meeting Scheduler Core

   1.  public class MeetingScheduler {
           private final List<Room> rooms;
           private final Map<String, Room> roomMap;
           private final AuditLogger auditLogger;
           private final SpillageOptimizer spillageOptimizer;
      
           // Different scheduling strategies
           public enum SchedulingStrategy {
               MIN_SPILLAGE,
               BEST_FIT_CAPACITY,
               ROUND_ROBIN,
               LEAST_UTILIZED
           }
      
           public Optional<String> scheduleMeeting(MeetingRequest request) {
               List<CandidateRoom> candidates = findCandidateRooms(request);
      
               if (candidates.isEmpty()) {
                   return Optional.empty();
               }
      
               // Apply optimization strategy
               CandidateRoom selected = spillageOptimizer.selectRoom(candidates, request);
      
               // Attempt to book with optimistic locking
               return attemptBookingWithRetry(selected, request);
           }
      
           private List<CandidateRoom> findCandidateRooms(MeetingRequest request) {
               List<CandidateRoom> candidates = new ArrayList<>();
      
               for (Room room : rooms) {
                   if (room.getCapacity() >= request.getCapacity()) {
                       if (room.isAvailable(request.getInterval())) {
                           double spillage = calculateSpillageForRoom(room, request);
                           candidates.add(new CandidateRoom(room, spillage));
                       }
                   }
               }
               return candidates;
           }
       }
      

**

Gaps / issues in design**

1. Too much logic in MeetingScheduler

   • findCandidateRooms is doing filtering + availability + spillage calculation.

   • Could be moved into:

     • RoomSelector / CandidateFinder, or

     • At least a separate component responsible for candidate discovery.

2. Enum SchedulingStrategy not wired in

   • Enum is declared but not used in scheduleMeeting; ideally SpillageOptimizer should be a family of strategies.

   • Better: Map<SchedulingStrategy, SchedulingStrategyHandler> or StrategyFactory.

3. Data structure for rooms

   • Assumes a simple List<Room> scan.

   • For big systems, would need:

     • Indexing by capacity,

     • Indexing by building / floor / equipment,

     • Sharding across nodes.

Concurrency issues in this design

Assume multiple threads calling scheduleMeeting simultaneously.

a) Check-then-act race on availability

Problem area:

if (room.isAvailable(request.getInterval())) {
    double spillage = calculateSpillageForRoom(room, request);
    candidates.add(new CandidateRoom(room, spillage));
}

Then later:

return attemptBookingWithRetry(selected, request);

Between isAvailable() and the actual booking:

• Another thread might book the same room for overlapping interval.

• Both threads saw available == true double booking risk.

b) Non-thread-safe data structures

• List<Room> rooms;

• Map<String, Room> roomMap;

If rooms can be added/removed at runtime:

• Concurrent modification without synchronization ConcurrentModificationException or stale views.

Even if the list itself is not mutated, Room internals (its schedule) are mutable and accessed from multiple threads must be made thread-safe.

c) Lost updates on room schedule

Room schedule is some structure (e.g., List<Booking>) inside Room.

• If two threads call room.addBooking(...) simultaneously without proper synchronization:

  • The underlying list / tree can be corrupted or some booking updates can be lost.

d) Thundering herd around popular time slots

If many users try to book for the same popular time:

• Lots of threads will compute candidates, all select the same best room, and then race to book it.

• Without control, this causes many retries/failures.

Concurrency control patterns to use

Will be covered in our course.

Improved Code Version

Will be covered in our course.

Description

You are given a string s of length N consisting only of the characters '(' and ')'. A parentheses string is considered valid if:

1. Every '(' has a matching ')' to its right.

2. No prefix of the string contains more ')' than '('.

Write a function:

boolean isValidParallel(String s, int P)

that determines whether s is valid, using P worker threads. Each thread can only read a disjoint substring of s.

Solution

1. Sequential Approach

private static boolean isValidSequential(String s) {
    int balance = 0;
    for (int i = 0; i < s.length(); i++) {
        if (s.charAt(i) == '(') {
            balance++;
        } else {
            balance--;
        }
        if (balance < 0) return false;
    }
    return balance == 0;
}

What is working here

• Simple and straightforward

• O(N) time complexity

• O(1) space complexity

• Easy to understand and debug

Drawbacks

• Cannot utilize multiple threads

• Doesn't meet the problem requirements for parallel processing

• Would be slow for extremely large strings

2. Naive Parallel Approach (Problematic)

// This approach doesn't work - just for discussion
boolean isValidNaiveParallel(String s, int P) {
    ExecutorService executor = Executors.newFixedThreadPool(P);
    int segmentSize = s.length() / P;
    Future<Boolean>[] futures = new Future[P];

    for (int i = 0; i < P; i++) {
        final int start = i * segmentSize;
        final int end = (i == P-1) ? s.length() : start + segmentSize;

        futures[i] = executor.submit(() -> {
            return isValidSequential(s.substring(start, end));
        });
    }

    // Collect results
    for (Future<Boolean> future : futures) {
        if (!future.get()) return false;
    }
    return true;
}

Why this fails:

• Each segment is validated independently, but validity depends on the entire prefix

• A segment might be locally valid but globally invalid due to balance dependencies

• Example: "())(" split as "())" and "(" - both segments fail local validation, but the real issue is global

3. Better Parallel Approach (The Working Solution)

static class SegmentResult {
    final int netBalance;
    final int minBalance;

    SegmentResult(int net, int min) {
        this.netBalance = net;
        this.minBalance = min;
    }
}

public static boolean isValidParallel(String s, int P) {
    // ... thread pool setup

    // Each thread processes its segment
    Future<SegmentResult>[] futures = new Future[P];
    for (int i = 0; i < P; i++) {
        final int start = i * segmentSize;
        final int end = Math.min(start + segmentSize, n);
        futures[i] = executor.submit(() -> processSegment(s, start, end));
    }

    // Sequential combination
    int currentBalance = 0;
    int globalMinBalance = 0;

    for (int i = 0; i < P; i++) {
        SegmentResult result = futures[i].get();
        globalMinBalance = Math.min(globalMinBalance, currentBalance + result.minBalance);
        currentBalance += result.netBalance;
    }

    return globalMinBalance >= 0 && currentBalance == 0;
}

This solution is great, but but what if we have very large P.

Solution 4

Will be covered in our course.

Design and implement a Paytm/PhonePe Wallet System that supports multiple concurrent users performing transactions at the same time. Your system should:

Features Required

1. User & Wallet Management

   • Each user has a unique wallet with balance.

   • Support wallet creation and balance inquiry.

2. Concurrent Transactions

   • Add money to wallet (via UPI, Card, NetBanking).

   • Send money from one wallet to another.

   • Handle concurrent deposits and transfers without race conditions.

3. Transaction Lifecycle

   • Each transaction can be PENDING SUCCESS / FAILED / REVERSED.

   • Ensure atomic debit/credit (no money disappears or duplicates even under concurrency).

4. Transaction Reliability

   • Idempotency (retries should not cause double debit).

   • Refund logic (if debit succeeds but credit fails, rollback debit).

5. Transaction History

   • Maintain mini-statement per user.

   • Show in descending order of time (latest first).

Solution approaches

🔑 Design Patterns to Use

1. Strategy Pattern Different funding sources (UPI/Card/NetBanking).

   1. Why Strategy?

      • Each payment source (UPI, Card, NetBanking) has the same high-level goal (fund wallet) but different implementation.

      • We want to swap/add new methods without modifying existing code.

   2. Why not Adapter?

      • Adapter is for integrating third-party APIs with different interfaces.

      • Here, we control the implementation; we dont need to adapt legacy/external code.

   3. Why not Bridge?

      • Bridge separates abstraction from implementation. Overkill here because abstraction (payment) and implementation (different sources) are already cleanly separated.

2. Template Method Pattern Standard transaction workflow (Validate Debit Credit Notify).

   1. Why Template?

      • All transactions (add money, transfer, refund) follow the same skeleton: validate debit/credit update status notify.

      • Only some steps differ (refund logic vs transfer logic).

   2. Why not Chain of Responsibility?

      • Chain is for passing requests along handlers dynamically. But our transaction flow is strict and sequential, not optional.

   3. Why not Command Pattern?

      • Command encapsulates actions as objects (undo/redo). We need structured workflow, not undo commands.

3. Factory Pattern Create the right Transaction object.

   1. Why Factory?

      • We need to create AddMoneyTransaction, SendMoneyTransaction, or RefundTransaction dynamically.

      • Centralized creation avoids if-else scattered everywhere.

   2. Why not Builder?

      • Builder is for stepwise object construction (useful for complex objects). Our transaction objects are straightforward.

   3. Why not Abstract Factory?

      • Abstract Factory creates families of related objects. Here, only one family exists (transactions).

4. Observer Pattern Notify users on transaction completion.

   1. Why Observer?

      • After a transaction, multiple services (SMS, Email, Push) need notification.

      • Observer decouples transaction logic from notification system.

   2. Why not Mediator?

      • Mediator centralizes communication between objects, but here we dont want a central coordinator, we want one-to-many updates.

   3. Why not Publisher-Subscriber with Message Queue?

      • That would be a distributed solution. For in-process design, Observer is sufficient.

5. State Pattern Handle transaction states (PENDING, SUCCESS, etc.).

   1. Why State?

      • A transaction can move from PENDING SUCCESS, or PENDING FAILED, etc.

      • Each state has different rules (e.g., SUCCESS cannot go back to PENDING).

   2. Why not Strategy?

      • Strategy is for choosing different algorithms. Here, we need to model object behavior change over time.

   3. Why not Enum with Switch Case?

      • Enums are fine for simple state. But extensibility suffers when adding new states or behaviors. State Pattern is more scalable.

6. Singleton Pattern TransactionManager (to avoid inconsistent transaction coordination).

   1. Why Singleton?

      • TransactionManager should coordinate transactions globally. Multiple instances would risk inconsistent tracking.

   2. Why not Static Class?

      • Static class prevents dependency injection/testing. Singleton provides controlled access + lazy initialization.

   3. Why not Monostate?

      • Monostate shares state across instances, but still allows multiple objects. For a central coordinator, true Singleton is cleaner.

🔥 Concurrency Challenges to Handle

• Race Condition: Two concurrent debits must not allow balance to go negative.

• Deadlock Avoidance: If two users send money to each other simultaneously, system should not deadlock.

• Atomicity: Debit and credit should be all-or-nothing.

• Thread-Safe Wallets: Ensure balance updates are synchronized correctly.

Concurrency Choices

1. Fine-Grained Locking per Wallet

   • Avoids blocking all transactions globally.

   • Why not Global Lock? Poor scalability; one user blocks all.

2. Consistent Lock Ordering (by UserId)

   • Prevents deadlock when two users transfer to each other.

   • Why not Random Locking? Leads to deadlocks.

3. Optimistic Concurrency (Version Check)

   • Not chosen here because wallet balances are critical safer with pessimistic locks.

Algorithms Involved

1. Concurrency Control Algorithm

   • Use fine-grained locks per wallet instead of global locks for scalability.

   • Always acquire locks in a consistent order (lower userId first) to avoid deadlocks.

2. Idempotency Algorithm

   • Maintain a transactionId status map.

   • If the same request is retried, return previous result.

3. Rollback Algorithm

   • If debit succeeds but credit fails, perform rollback.

4. Mini-Statement Algorithm

   • Use a priority queue / sorted list for recent transactions.

Code

Covered in our premium course

A logistics company has multiple loading docks where workers load packages into delivery trucks.

• Each truck has a weight/volume limit.

• Packages arrive continuously from the warehouse.

• Multiple workers can attempt to load packages in parallel.

• Once a truck is full, it should be dispatched immediately, and a new empty truck should arrive at the dock.

Concurrency Challenge

Naive approach:
Each worker checks whether the truck has space left and then puts the package in.

Problems

• Two workers check simultaneously both see space available.

• Both load packages truck exceeds capacity.

• Or, one worker sees truck is full, but another worker just dispatched it confusion: packages might get lost or assigned incorrectly.

🔑 Solution Approaches

1. Naive Locking

• Place a synchronized lock on the truck while loading.

• Multiple workers try to load packages onto a docks current truck.

  • Correctness first: never overfill a truck; never dispatch twice; never lose a package.

    • Only one worker can load at a time.

• Well serialize critical operations with a single lock so only one worker mutates truck state at a time.

🔒 Locking plan (coarse-grained / monitor)

• Use one monitor lock per dock (i.e., synchronized on the Dock instance).

  • Why lock the dock (not the truck)?

    • We will discuss this in our course.

• Every operation that reads + writes truck capacity/used/state runs inside the same lock.

• The whole sequence check load maybe dispatch maybe replace is atomic w.r.t. other workers.

Code

import java.util.*;
import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicInteger;

public class NaiveDockLoading {

    // Simple package with a weight
    static class Package {
        final int id;
        final int weight;
        Package(int id, int weight) { this.id = id; this.weight = weight; }
        @Override public String toString() { return "Pkg#" + id + "(" + weight + ")"; }
    }

    enum TruckState { EMPTY, LOADING, FULL, DISPATCHED }

    static class Truck {
        final int id;
        final int capacity;
        int used = 0;
        TruckState state = TruckState.EMPTY;
        final List<Package> loaded = new ArrayList<>();

        Truck(int id, int capacity) {
            this.id = id;
            this.capacity = capacity;
        }
    }

    static class Dock {
        private final int truckCapacity;
        private final AtomicInteger truckSeq = new AtomicInteger(1);
        private Truck currentTruck;

        // One coarse-grained lock: the Dock object itself
        Dock(int truckCapacity) {
            this.truckCapacity = truckCapacity;
            this.currentTruck = new Truck(truckSeq.getAndIncrement(), truckCapacity);
        }

        // Called by many worker threads
        public void load(Package pkg) {
            synchronized (this) {
                ensureActiveTruck();

                // If it doesn't fit, dispatch and replace, then load on the new truck.
                if (!fits(pkg, currentTruck)) {
                    dispatchLocked(currentTruck);
                    currentTruck = new Truck(truckSeq.getAndIncrement(), truckCapacity);
                }

                // Now it must fit
                placeLocked(pkg, currentTruck);

                // If truck just became full, dispatch and replace
                if (currentTruck.used == currentTruck.capacity) {
                    currentTruck.state = TruckState.FULL;
                    dispatchLocked(currentTruck);
                    currentTruck = new Truck(truckSeq.getAndIncrement(), truckCapacity);
                }
            } // lock released
        }

        private void ensureActiveTruck() {
            if (currentTruck.state == TruckState.DISPATCHED) {
                currentTruck = new Truck(truckSeq.getAndIncrement(), truckCapacity);
            }
        }

        private static boolean fits(Package p, Truck t) {
            return t.used + p.weight <= t.capacity && t.state != TruckState.DISPATCHED;
        }

        private static void placeLocked(Package p, Truck t) {
            // Inside dock lock: check+update is atomic
            if (t.state == TruckState.DISPATCHED) {
                throw new IllegalStateException("Cannot load on dispatched truck " + t.id);
            }
            if (t.used + p.weight > t.capacity) {
                throw new IllegalStateException("Overfill prevented for truck " + t.id);
            }
            if (t.used == 0) t.state = TruckState.LOADING;
            t.loaded.add(p);
            t.used += p.weight;
            System.out.printf("[DOCK] Loaded %s on truck #%d (used=%d/%d)%n",
                    p, t.id, t.used, t.capacity);
        }

        private static void dispatchLocked(Truck t) {
            if (t.state == TruckState.DISPATCHED) return; // idempotent
            t.state = TruckState.DISPATCHED;
            System.out.printf("[DISPATCH] Truck #%d dispatched with %d/%d (packages=%d)%n",
                    t.id, t.used, t.capacity, t.loaded.size());
            // In naive solution: pretend to hand off to transport subsystem here.
            // Avoid I/O here to keep critical section small (still naive, but less awful).
        }
    }

    // Demo harness: many workers calling Dock.load(...)
    public static void main(String[] args) throws InterruptedException {
        Dock dock = new Dock(/*truckCapacity*/ 100);

        // Create a pool of workers; they all contend on the same dock lock.
        ExecutorService workers = Executors.newFixedThreadPool(8);

        // Generate random packages totaling more than a few trucks
        List<Package> incoming = new ArrayList<>();
        Random r = new Random(42);
        for (int i = 1; i <= 60; i++) {
            int w = 5 + r.nextInt(30); // 5..34
            incoming.add(new Package(i, w));
        }

        for (Package p : incoming) {
            workers.submit(() -> dock.load(p));
        }

        workers.shutdown();
        workers.awaitTermination(1, TimeUnit.MINUTES);
        System.out.println("Done.");
    }
}

Performance & limits (what breaks first)

• All workers queue behind the dock lock; CPU underutilization grows as worker count rises.

• Even if you wanted to prepare a new truck in parallel, the single lock blocks it.

• Javas intrinsic locks are not fair; a thread might repeatedly win the lock (lock hogging), causing starvation under load spikes.

• If package arrival rate > service rate, the work queue grows unbounded (in this naive example, we submit tasks freely).

More Better Solutions Approaches and Fix for above problems will be covered in our course.

Were building a digital jigsaw puzzle game (or simulation) where:

• The puzzle has many pieces (hundreds or thousands).

• Each piece can be placed independently unless it connects to another.

• We want to speed up building the puzzle by letting multiple workers (threads) place pieces at the same time.

Solution Approaches

1 Step 1 The Naive Single-Threaded Approach

Imagine we have a jigsaw puzzle with 1,000 pieces.
We write a simple loop:

public class PuzzleBuilder {
    public static void main(String[] args) {
        for (int piece = 1; piece <= 1000; piece++) {
            placePiece(piece);
        }
    }

    static void placePiece(int id) {
        System.out.println("Placed piece " + id);
        try { Thread.sleep(10); } catch (InterruptedException e) {}
    }
}

📝 Idea: One person places all pieces in order.
Works fine for small puzzles.
But slow for large puzzles only one worker is active.

The Real-World Problem

In real life:

• Multiple people can work on different parts of the puzzle at the same time.

• We dont need to place pieces in strict numeric order only in correct locations.

• Our single-thread version wastes potential parallelism.

More Solutions

will be discussed in our course.

Problem Statement

• Multiple packing stations process orders simultaneously

• Shared inventory with limited stock

• Orders may require multiple items

• Prevent race conditions during inventory access

• Handle backorders when stock is insufficient

Solution Approaches

Basic Solution

public class Warehouse {
    private Map<String, Integer> inventory = new HashMap<>();

    public boolean pickItem(String sku, int quantity) {
        if (inventory.getOrDefault(sku, 0) >= quantity) {
            inventory.put(sku, inventory.get(sku) - quantity);
            return true;
        }
        return false;
    }

    public void restock(String sku, int quantity) {
        inventory.put(sku, inventory.getOrDefault(sku, 0) + quantity);
    }
}

public class PackingStation {
    public void processOrder(Order order, Warehouse warehouse) {
        for (Map.Entry<String, Integer> item : order.getItems().entrySet()) {
            if (!warehouse.pickItem(item.getKey(), item.getValue())) {
                order.backorder();
                return;
            }
        }
        order.pack();
    }
}

Problems

1. Race Condition: Two threads can oversell stock

   

2. Dirty Reads: Temporary negative inventory possible

3. Lost Updates: Restocks might get overwritten

Fix for Above mentioned problem: Coarse-Grained Synchronization

public class Warehouse {
    private Map<String, Integer> inventory = new HashMap<>();

    public synchronized boolean pickItem(String sku, int quantity) {
        if (inventory.getOrDefault(sku, 0) >= quantity) {
            inventory.put(sku, inventory.get(sku) - quantity);
            return true;
        }
        return false;
    }

    public synchronized void restock(String sku, int quantity) {
        inventory.put(sku, inventory.getOrDefault(sku, 0) + quantity);
    }
}

1. Solves race conditions with method-level synchronized

2. Ensures atomic inventory updates

New Problems

Throughput Bottleneck:

• Entire warehouse locks during each operation

• Packing station working with SKU-A blocks SKU-B access

  

Deadlock Risk:

// Thread 1
synchronized void processOrder() {
    pickItem("A", 1);
    pickItem("B", 1); // Deadlock if Thread 2 holds B and wants A
}

Fix and other solution will be covered in our course.

Simulate an online matchmaking system where:

• Players join a matchmaking queue in real-time.

• When enough players are available (say, 4 or 10), a match is created.

• Players are then removed from the queue, and a game session is started.

Solution Approaches

Naive / Basic Implementation

we just keep a normal list of players waiting for a match.

import java.util.*;

public class NaiveMatchmaking {
    static final int PLAYERS_PER_MATCH = 4;
    static List<Integer> waitingPlayers = new ArrayList<>();

    public static void main(String[] args) {
        // Players joining (simulated)
        for (int i = 1; i <= 8; i++) {
            joinQueue(i);
        }
    }

    static void joinQueue(int playerId) {
        waitingPlayers.add(playerId);
        System.out.println("🙋 Player #" + playerId + " joined queue.");

        if (waitingPlayers.size() >= PLAYERS_PER_MATCH) {
            startMatch();
        }
    }

    static void startMatch() {
        List<Integer> matchPlayers = waitingPlayers.subList(0, PLAYERS_PER_MATCH);
        System.out.println("🎮 Match started: " + matchPlayers);
        matchPlayers.clear(); // remove them from queue
    }
}

Problem Concurrency Breaks This

Now, in real life:

• Players join in parallel (multiple threads)

• Matches are formed in real-time

• The list waitingPlayers is not thread-safe Race conditions happen:

  • Two threads may see enough players and start the same match twice.

  • Players may be skipped or duplicated.

  • Modifying the same list from multiple threads ConcurrentModificationException.

Example failure scenario:

Thread 1: sees 4 players starting match...
Thread 2: sees same 4 players starting another match...

First Fix Add Locks (synchronized)

try to fix it by synchronizing the join method.

static synchronized void joinQueue(int playerId) {
    waitingPlayers.add(playerId);
    if (waitingPlayers.size() >= PLAYERS_PER_MATCH) {
        startMatch();
    }
}

static synchronized void startMatch() {
    List<Integer> matchPlayers = new ArrayList<>(waitingPlayers.subList(0, PLAYERS_PER_MATCH));
    System.out.println("🎮 Match started: " + matchPlayers);
    waitingPlayers.removeAll(matchPlayers);
}

This works for correctness.
But:

• It blocks all player joins when one player is joining or a match is starting slower.

• If you scale to thousands of players, this becomes a bottleneck.

Better Approach

will be covered in our course.

Simulate a call center where:

• There are a limited number of agents (say 3).

• Many customers (calls) are coming in at the same time.

• If all agents are busy, new calls must wait in a queue until an agent becomes free.

Only available agents can take calls.
The system should not lose any calls and must not assign 2 agents to the same call.

Solution Approaches

Basic Thread Pool Approach (Fixed Agents)

1. We'll use a fixed thread pool where:

   • Each thread represents an agent

   • Incoming calls are tasks submitted to the executor

   • The executor automatically handles queuing when all agents are busy

    import java.util.concurrent.*;

    public class BasicCallCenter {
        // 1. Configuration
        private static final int AGENT_COUNT = 3; 
        private static ExecutorService agents = Executors.newFixedThreadPool(AGENT_COUNT);

        // 2. Call Task Representation
        static class Call implements Runnable {
            private final int callId;

            public Call(int id) { 
                this.callId = id; 
            }

            public void run() {
                // 3. Call Handling Logic
                System.out.println("📞 Call " + callId + " started by " + 
                                  Thread.currentThread().getName());

                try {
                    // Simulate variable call duration (2-7 seconds)
                    Thread.sleep(2000 + (long)(Math.random() * 5000)); 
                } catch (InterruptedException e) {
                    System.out.println(" Call " + callId + " interrupted");
                }

                System.out.println(" Call " + callId + " completed");
            }
        }

        // 4. Simulation Driver
        public static void main(String[] args) {
            // Simulate 10 incoming calls
            for (int i = 1; i <= 10; i++) {
                agents.execute(new Call(i)); // 5. Dispatch calls
                System.out.println("🔔 Received call #" + i);

                // Random delay between calls (0-1s)
                try { Thread.sleep((long)(Math.random() * 1000)); 
                } catch (InterruptedException e) {}
            }

            // 6. Clean shutdown
            agents.shutdown();
        }
    }

Non-Working Test Cases

1. Sustained Overload (Memory Crash)

Continuous call flood.

10,000 calls with 3 agents

    for (int i = 1; i <= 10_000; i++) {
        agents.execute(new Call(i));
    }

OutOfMemoryError: Unable to create new native thread

Unbounded queue grows indefinitely, consuming all memory.

2. Call Rejection Needed

Queue at capacity (business requirement), Attempt to queue 6th call when max capacity is 5
Silently accepts all calls
Should reject calls when overloaded
Solution: Use ThreadPoolExecutor with bounded queue:

ExecutorService agents = new ThreadPoolExecutor(
    3, 3, 0L, TimeUnit.MILLISECONDS,
    new ArrayBlockingQueue<>(5), // Bounded queue
    new ThreadPoolExecutor.AbortPolicy() // Rejection handler
);

More Cases and Other Approaches are covered in our course.

Before the rocket can launch, it must pass several system checks (e.g., fuel, navigation, engine, weather, etc.).

Each system is checked independently by a different thread.

👉 Only after all checks are complete, the main launch system can proceed and say:

"All systems go. Launching!"

Solution Approaches

1. Basic Thread Join Approach

   1. Create threads - One thread for each system check (fuel, navigation, etc.)

   2. Start all threads - All checks run simultaneously

   3. Wait for completion - Main thread waits until all checks finish

   4. Launch - Only proceed if all checks were successful

public class RocketLaunchBasic {

    // Task for checking individual systems
    static class SystemCheck implements Runnable {
        private final String systemName;

        public SystemCheck(String name) {
            this.systemName = name;
        }

        public void run() {
            try {
                // Simulate check time (0-2 seconds)
                System.out.println(" Checking " + systemName + "...");
                Thread.sleep((long)(Math.random() * 2000));
                System.out.println(systemName + " ");
            } catch (InterruptedException e) {
                System.out.println(systemName + "  (Interrupted)");
            }
        }
    }

    public static void main(String[] args) throws InterruptedException {
        String[] systems = {"Fuel", "Navigation", "Engine", "Weather", "Comm"};

        // 1. Create threads for all systems
        Thread[] threads = new Thread[systems.length];
        for (int i = 0; i < systems.length; i++) {
            threads[i] = new Thread(new SystemCheck(systems[i]));
        }

        // 2. Start all checks in parallel
        System.out.println("🚀 Starting pre-launch checks...");
        for (Thread t : threads) {
            t.start(); // Launch parallel execution
        }

        // 3. Wait for all to complete
        for (Thread t : threads) {
            t.join(); // Block until thread finishes
        }

        // 4. Final verification
        System.out.println("\n🔍 All checks completed!");
        System.out.println("🚀 All systems go. Launching!");
    }
}

Failure Test Cases

1. Thread Never Completes (Deadlock)

One system check hangs indefinitely. Lets say one of started thread never finish its run.

public void run() {
    if (systemName.equals("Fuel")) {
        while(true) { /* Infinite loop */ } 
    }
    // ... normal check ...
}

Checking Fuel...
Checking Navigation...
Navigation ...
(Program hangs forever)

To fix this, use join(timeout), which will only wait for specific amount of time

for (Thread t : threads) {
    t.join(3000); // Wait max 3 seconds
    if (t.isAlive()) {
        System.out.println(" " + systemName + " timeout!");
        t.interrupt();
    }
}

2. Exception in System Check

Thread crashes during check.

public void run() {
    if (systemName.equals("Navigation")) {
        throw new RuntimeException("Sensor error");
    }
    // ... normal check ...
}

Checking Fuel...
Checking Navigation...
Checking Engine...
Exception in thread "Thread-1" java.lang.RuntimeException: Sensor error
Fuel
Engine

🔍 All checks completed!
🚀 All systems go. Launching! ( Despite failure!)

How we will fix this ?, will be covered in our course.

More Approaches and Failing Test Cases will be covered in our course.

• 10-15 players (threads) interact in real-time

• Shared state: Player positions, tasks, voting, emergency meetings

• Critical requirements:

  • No two players can report a body simultaneously

  • Emergency meetings must serialize discussions

  • Task progress must be atomic

  • Deadlock-free voting

💡 Solution Approaches

1. Synchronized Everything

This is the simplest way to make your multiplayer game thread-safe, perfect for beginners learning concurrency. Let's break it down completely.

public class Game {
    // Shared game state
    private int playersOnline = 0;
    private boolean gameStarted = false;

    // All methods are synchronized
    public synchronized void playerJoin() {
        playersOnline++;
    }

    public synchronized void startGame() {
        if (playersOnline >= 4) {
            gameStarted = true;
        }
    }
}

What "synchronized" Actually Does

1. Lock Acquisition: When a thread enters any synchronized method:

   • It acquires the object's intrinsic lock (also called the monitor lock)

   • Other threads must wait if the lock is held

2. Memory Visibility:

   • When the lock is released, all changes become visible to other threads

   • When the lock is acquired, it sees the latest changes

3. Atomic Execution:

   • The entire method runs without interruption from other threads

Test Cases

1. Normal Operation (Single Thread)

Scenario: One player joins the game
Expected: Counter increments correctly

Game game = new Game();
game.playerJoin();
assert game.getPlayersOnline() == 1;  // Passes

2. Concurrent Joins (Race Condition Prevented)

Scenario: Two players join simultaneously
Expected: Counter shows 2 without corruption

Game game = new Game();

Thread t1 = new Thread(() -> game.playerJoin());
Thread t2 = new Thread(() -> game.playerJoin());

t1.start();
t2.start();
t1.join();
t2.join();

assert game.getPlayersOnline() == 2;  // Always passes

3. Mixed Operations (Join + Start Game)

Scenario: One joins while another tries to start game
Expected: Game starts only if 4 players

//  Without synchronization:
if (playersOnline >= 4) {  // Race condition
    gameStarted = true;
}

Critical Risks

All Critical Risks and other approaches will be covered in our course.

Problem Statement

• Multiple threads (ATM users, online banking) access shared bank accounts.

• Operations:

  • deposit(amount)

  • withdraw(amount)

  • getBalance()

• Requirements:

  1. Thread-safe: No race conditions during concurrent transactions.

  2. Consistency: Balance never goes negative (unless overdraft allowed).

  3. Deadlock-free: No circular waits between accounts (e.g., transfer between A and B).

💡 Solution Approaches

1. Basic Thread-Safe Account (Synchronized Methods)

To make the BankAccount thread-safe, we start by marking the deposit, withdraw, and getBalance methods as synchronized so only one thread can access them at a time per object.

Key Mechanics

• Every Java object has an intrinsic lock (monitor).

• synchronized methods acquire this lock before execution.

• Only one thread can hold the lock at a time all other threads block.

• 💡

  However, if two threads operate on different objects, synchronization won't help because each object has a different lock.

public class BankAccount {
    private double balance;

    public synchronized void deposit(double amount) {
        balance += amount;
    }

    public synchronized void withdraw(double amount) throws InsufficientFundsException {
        if (balance < amount) throw new InsufficientFundsException();
        balance -= amount;
    }

    public synchronized double getBalance() {
        return balance;
    }
}

Case 1: Simple Deposit-Withdraw (No Conflict)

BankAccount account = new BankAccount();
// Thread 1
account.deposit(100);  //  Balance = 100
// Thread 2
account.withdraw(30);   //  Balance = 70

Case 2: Concurrent Deposits (Lost Update Problem Prevented)

Case 3: Overdraft Prevention

// Thread 1
account.withdraw(150);  //  Fails (balance=100)
// Thread 2
account.getBalance();   //  Returns 100 (consistent read)

Where It Fails (Edge Cases)

Problem 1: Nested Operations Deadlock

Consider if we are going to use this Object and tranfering money from one account to another

// Thread 1
synchronized void transfer(BankAccount to, double amount) {
    this.withdraw(amount);    // Already holds lock on 'this'
    to.deposit(amount);      // Needs lock on 'to'  DEADLOCK if another thread does reverse transfer
}

Problem 2: Liveness Issues (Performance)

• All operations serialize (even getBalance() blocks writes).

• Under high contention, throughput plummets.

Problem 3: Compound Actions Not Atomic

if (account.getBalance() >= 100) {  // Race condition!
    account.withdraw(100);          // Balance may change between check and withdraw
}
// Operation is not Atomic, may cause issue if any changes happen between two operations.

More Apporaches, Explanation and Fixes of above problem will covered in our course.

Problem Statement

• Multiple trains run on a shared circular track (like a subway loop).

• Only one train can occupy a track segment at a time (mutual exclusion).

• Trains must avoid collisions (race conditions) and deadlocks (gridlock where all trains are stuck waiting).

• Goal: Implement a thread-safe system where trains move without crashing or freezing.

💡 Solution Approaches

1. Basic Version (Using Semaphores)

• Each track segment is guarded by a semaphore (1 permit = available, 0 = occupied).

• Trains acquire the next segments semaphore before moving.

• Risk: If all trains hold one segment and wait for the next circular deadlock.

Java Implementation

import java.util.concurrent.Semaphore;

public class TrainDeadlockBasic {
    static final int NUM_SEGMENTS = 5;
    static Semaphore[] segments = new Semaphore[NUM_SEGMENTS];

    public static void main(String[] args) {
        // Initialize segments (all available initially)
        for (int i = 0; i < NUM_SEGMENTS; i++) {
            segments[i] = new Semaphore(1);
        }

        // Create 3 trains (threads)
        for (int i = 0; i < 3; i++) {
            new Thread(new Train(i)).start();
        }
    }

    static class Train implements Runnable {
        private int id;
        private int currentSegment;

        public Train(int id) {
            this.id = id;
            this.currentSegment = id % NUM_SEGMENTS; // Start at different segments
        }

        @Override
        public void run() {
            while (true) {
                try {
                    int nextSegment = (currentSegment + 1) % NUM_SEGMENTS;

                    System.out.printf("Train %d WAITING for segment %d\n", id, nextSegment);
                    segments[nextSegment].acquire(); // Request next segment
                    System.out.printf("Train %d ENTERED segment %d\n", id, nextSegment);

                    Thread.sleep(1000); // Simulate travel time

                    segments[currentSegment].release(); // Leave current segment
                    System.out.printf("Train %d LEFT segment %d\n", id, currentSegment);

                    currentSegment = nextSegment;
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }
        }
    }
}

Problem: Deadlock Risk!

• If all trains hold their current segment and wait for the next system freezes.

• Example:

  • Train 0 holds S0, waits for S1.

  • Train 1 holds S1, waits for S2.

  • Train 2 holds S2, waits for S0.
    Circular deadlock!

Fix for above mentioned problem and more apporaches will be covered in our course

Problem Statement:
Simulate a traffic intersection where:

• Multiple roads (threads) lead to a single intersection (shared resource).

• Only one direction of traffic can pass at a time (mutual exclusion).

• Traffic lights (semaphores/locks) control access to avoid accidents (race conditions).

• Bonus: Add turn lanes, pedestrian crossings, or emergency vehicle priority.

💡 Possible Solutions & Approaches

1. Basic Version (4-Way Intersection)

   

   At a busy four-way intersection, there's no traffic light, but a smart controller is in charge. Each road North, South, East, and West has a gatekeeper (a semaphore) that starts locked (red light 🚫).

   The controller runs forever in a loop:

   1. It opens the North and South gates (green light 🟢) and lets one car from each direction pass.

   2. After 5 seconds, it closes those gates (red light again 🔴).

   3. Then it opens the East and West gates for 5 seconds and lets a car from each direction pass.

   4. Repeat forever

🚗 Meanwhile, from each direction, cars keep arriving but they stop at the gate and wait (using acquire()) until the controller lets them go.

Once the light turns green (via release()), a car goes through, thanks the controller, and may or may not leave the gate open for the next car (depending on whether the car calls release() again).

This way, order and safety are maintained at the intersection using semaphores and no crashes happen!

import java.util.concurrent.Semaphore;

public class TrafficLightBasic {
    // Semaphores for each direction (initially 0 = RED)
    private static Semaphore north = new Semaphore(0);
    private static Semaphore south = new Semaphore(0);
    private static Semaphore east = new Semaphore(0);
    private static Semaphore west = new Semaphore(0);

    public static void main(String[] args) {
        // Traffic light controller thread
        Thread controller = new Thread(() -> {
            while (true) {
                try {
                    System.out.println("\n🟢 NORTH/SOUTH GREEN");
                    north.release(); // Green for North
                    south.release(); // Green for South
                    Thread.sleep(5000); // 5 sec green light
                    north.acquire(); // Back to red
                    south.acquire();

                    System.out.println("\n🟢 EAST/WEST GREEN");
                    east.release();
                    west.release();
                    Thread.sleep(5000);
                    east.acquire();
                    west.acquire();
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }
        });
        controller.setDaemon(true);
        controller.start();

        // Simulate cars arriving from different directions
        new Thread(() -> car(north, "North Car")).start();
        new Thread(() -> car(south, "South Car")).start();
        new Thread(() -> car(east, "East Car")).start();
        new Thread(() -> car(west, "West Car")).start();
    }

    private static void car(Semaphore sem, String name) {
        while (true) {
            try {
                sem.acquire(); // Wait for green light
                System.out.println(name + " is passing through!");
                Thread.sleep(1000); // Time to cross intersection
                sem.release(); // Not strictly needed if controller handles it
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
    }
}

More Solution will be discussed in our course.