PROLOGUE

Elevators look simple: press a button, wait, ride. But the moment a building has more than one car, we are solving a scheduling problem with real people waiting. Which car answers which call? What do idle cars do? What happens at 9 AM when everyone arrives at once? It’s also a great LLD question, because it forces us to model state, choose algorithms, and keep concurrency under control.

I had a lot of fun playing this game in my childhood, anyone remembers?

1. What are we building?

A system that controls M elevators serving N floors, accepts passenger requests, and decides how cars move.

Functional requirements

1. Passengers press UP/DOWN at a floor (a hall call)
2. Passengers press a destination floor inside the car (a car call)
3. Multiple elevators operate together.
4. Doors open and close, and the car stops at requested floors.
5. Support emergency stop, maintenance mode, and overload detection.

Non-functional requirements

1. Minimize average wait time (call to pickup)
2. Minimize worst-case wait, so nobody starves
3. Safe by default: safety logic always beats scheduling logic
4. Fault tolerant: one broken car must not stop the building
5. Extensible: swap scheduling algorithms without rewriting the system

This distinction drives the whole design. A car call is already assigned to a car. A hall call must be assigned by the system, and that assignment is the interesting problem.

2. Core entities

Building
 ├── List<Floor>
 ├── List<ElevatorCar>
 └── ElevatorDispatcher ── uses ──► DispatchStrategy

ElevatorCar
 ├── id, currentFloor, direction, state
 ├── capacity / currentLoad
 ├── upStops, downStops   (pending stops)
 └── Door

Requests
 ├── HallCall (floor, direction, timestamp)
 └── CarCall  (carId, destinationFloor)

Separate the car from the dispatcher. The car knows how to move and serve stops. The dispatcher knows which car should get which call. Mixing the two is the most common LLD mistake here.

3. The elevator state machine

Every car is always in exactly one state:

Modeling this explicitly (State pattern or an enum with a switch) makes the safety rules easy to enforce. For example, never move while DOORS_OPEN becomes a one-line guard instead of scattered if statements.

4. First steps — Single elevator: How should a car move?

Option 1: FCFS (First Come, First Served)

Serve requests in arrival order.

• Pros: trivial, perfectly fair in ordering
• Cons: wildly inefficient. A car at floor 10 told to go to 2, then 9, then 3 zigzags needlessly.

Option 2: SSTF (Shortest Seek Time First)

Always go to the nearest pending stop.

• Pros: short average trips
• Cons: starvation. A request at floor 40 can wait forever while floors 1 to 5 keep generating calls.

Option 3: SCAN

Keep moving in one direction, serving every stop on the way, until we reach the end. Then reverse.

• Pros: efficient and starvation-free (every floor is visited each sweep)
• Cons: wastes time traveling to the building’s end when nobody’s there

Option 4: LOOK (what is recommended and used)

SCAN, but reverse at the last pending stop instead of the last floor. Real elevators use LOOK-style logic because it matches how people think: a car going up picks up everyone going up, then turns around.

Implementing LOOK in JAVA

Each car keeps two sorted sets: stops to serve while going up and stops to serve while going down. The set a stop goes into depends on which direction the passenger wants to travel, not just where the stop is.

public enum Direction { UP, DOWN }
public enum ElevatorState { IDLE, MOVING, DOORS_OPEN, OUT_OF_SERVICE }

public class ElevatorCar {
    private static final int DOOR_OPEN_TICKS = 3;

    private final int id;
    private final TreeSet<Integer> up = new TreeSet<>();    // serve while moving UP
    private final TreeSet<Integer> down = new TreeSet<>();  // serve while moving DOWN

    private int floor = 0;
    private Direction direction = Direction.UP;
    private ElevatorState state = ElevatorState.IDLE;
    private int doorTicks;

    public ElevatorCar(int id) { this.id = id; }

    /** Hall call: stop here, to pick up someone heading in `dir`. */
    public synchronized void assignHallCall(int targetFloor, Direction dir) {
        (dir == Direction.UP ? up : down).add(targetFloor);
    }

    /** Car call: passenger inside pressed a floor button. */
    public synchronized void pressFloor(int targetFloor) {
        (targetFloor >= floor ? up : down).add(targetFloor);
    }

    /** One simulation step (e.g. 1 second). */
    public synchronized void tick() {
        if (state == ElevatorState.OUT_OF_SERVICE) return;

        if (state == ElevatorState.DOORS_OPEN) {
            if (--doorTicks > 0) return;
            state = ElevatorState.IDLE;                 // doors closed, decide next move
        }

        OptionalInt target = nextTarget();
        if (target.isEmpty()) { state = ElevatorState.IDLE; return; }

        if (target.getAsInt() == floor) { arrive(); return; }

        state = ElevatorState.MOVING;
        floor += target.getAsInt() > floor ? 1 : -1;
    }

    /** LOOK: keep sweeping in the current direction; reverse only when nothing is ahead. */
    private OptionalInt nextTarget() {
        for (int attempt = 0; attempt < 2; attempt++) {
            if (direction == Direction.UP) {
                Integer t = up.ceiling(floor);                          // next stop ahead
                if (t == null && !down.isEmpty() && down.last() > floor)
                    t = down.last();                                    // turnaround point
                if (t != null) return OptionalInt.of(t);
                direction = Direction.DOWN;                             // nothing ahead: reverse
            } else {
                Integer t = down.floor(floor);
                if (t == null && !up.isEmpty() && up.first() < floor)
                    t = up.first();
                if (t != null) return OptionalInt.of(t);
                direction = Direction.UP;
            }
        }
        return OptionalInt.empty();                                     // nothing pending
    }

    private void arrive() {
        boolean served = (direction == Direction.UP ? up : down).remove(floor);
        if (!served) (direction == Direction.UP ? down : up).remove(floor); // turnaround stop
        state = ElevatorState.DOORS_OPEN;
        doorTicks = DOOR_OPEN_TICKS;
        // notify listeners: onArrived(this, floor, direction)
    }

    // getters used by the dispatcher
    public synchronized int floor()              { return floor; }
    public synchronized Direction direction()    { return direction; }
    public synchronized boolean isIdle()         { return state == ElevatorState.IDLE && up.isEmpty() && down.isEmpty(); }
    public synchronized boolean isOutOfService() { return state == ElevatorState.OUT_OF_SERVICE; }
    public synchronized int pendingStops()       { return up.size() + down.size(); }
    public synchronized int id()                 { return id; }
}

Note the tick-based design. Instead of real threads sleeping between floors, the car advances one step per tick. This makes the system deterministic and unit-testable, because it can run 10,000 ticks in a test in milliseconds. This is simplified; production code also handles overload, door obstruction, and maintenance transitions.

5. Now the main problem -> Multiple elevators: the dispatching problem

Now the real question. A hall call arrives at floor 7 (UP). Which of the M cars should handle it? Here are some brute force strategies, and reasons why they fail!

Nearest by distance is wrong because distance is not time. What matters is the estimated time of arrival (ETA), which depends on direction, existing stops, and load.

The cost-based approach (the standard answer)

For each car, compute a cost representing how long the passenger would wait. Assign the call to the cheapest car.

public interface DispatchStrategy {
    ElevatorCar select(List<ElevatorCar> cars, HallCall call);
}

public class CostBasedStrategy implements DispatchStrategy {
    private static final int STOP_PENALTY = 3;       // ~ticks lost per extra stop (doors + decel)
    private static final int INF = Integer.MAX_VALUE;

    @Override
    public ElevatorCar select(List<ElevatorCar> cars, HallCall call) {
        return cars.stream()
                .filter(c -> !c.isOutOfService())
                .min(Comparator.comparingInt((ElevatorCar c) -> cost(c, call))
                        .thenComparingInt(ElevatorCar::pendingStops))   // tie-break: least busy
                .orElseThrow(() -> new IllegalStateException("No elevator available"));
    }

    private int cost(ElevatorCar car, HallCall call) {
        int dist = Math.abs(car.floor() - call.floor());

        // Case 1: idle car, so just the travel distance
        if (car.isIdle()) return dist;

        // Case 2: car is heading toward the caller in the same direction, so it's on the way
        boolean sameDir = car.direction() == call.direction();
        boolean ahead = call.direction() == Direction.UP
                ? call.floor() >= car.floor()
                : call.floor() <= car.floor();
        if (sameDir && ahead) {
            return dist + STOP_PENALTY * car.pendingStops();
        }

        // Case 3: car must finish its current sweep, turn around, then come back
        // (simplified: charge a full sweep plus the return distance)
        int sweep = car.pendingStops() * STOP_PENALTY;
        return dist + sweep + 2 * Math.abs(car.floor() - call.floor()); // pessimistic estimate
    }
}

The three cases capture the intuition:

1. Idle car: cost is just the distance
2. Moving toward you, same direction: cost is the distance plus the delay from stops along the way
3. Moving away or the wrong way: it has to finish, reverse, and return, so it’s heavily penalized

The constants (STOP_PENALTY, etc.) are tunable parameters. In real systems they’re calibrated from measured door times and car speeds. A more accurate variant is to dry-run simulate a copy of each car with the call added and measure ticks until pickup. It costs more compute but reuses the exact movement logic, and with 8 cars and 40 floors the cost is negligible.

The dispatcher

Note here :- Because the strategy is injected, switching from cost-based to zoned to destination-dispatch (below) is a one-line change, which is the point of the Strategy pattern.

public class ElevatorDispatcher {
    private final List<ElevatorCar> cars;
    private volatile DispatchStrategy strategy;
    private final Set<HallCallKey> pending = ConcurrentHashMap.newKeySet();

    public ElevatorDispatcher(List<ElevatorCar> cars, DispatchStrategy strategy) {
        this.cars = cars;
        this.strategy = strategy;
    }

    public void onHallCall(int floor, Direction dir) {
        // Passengers mash buttons; ignore duplicates for an already-pending call
        if (!pending.add(new HallCallKey(floor, dir))) return;

        HallCall call = new HallCall(floor, dir, Instant.now());
        ElevatorCar chosen = strategy.select(cars, call);
        chosen.assignHallCall(floor, dir);
    }

    // Called by the car's "arrived" event so the button can be pressed again
    public void onArrived(int floor, Direction dir) {
        pending.remove(new HallCallKey(floor, dir));
    }

    public void setStrategy(DispatchStrategy s) { this.strategy = s; }   // swap at runtime
}

All the design patterns at a glance

6. Concurrency

Passengers press buttons at any time, while cars are moving. Three sensible models, from simplest to most scalable:

1. Single-threaded event loop (recommended to start): all requests go onto a queue. One scheduler thread drains the queue and calls tick() on every car. No locks needed, and fully deterministic.
2. Thread per car: each car runs its own loop, and synchronized methods protect its stop sets (as in the code above). The dispatcher reads car state while cars mutate it, so we need snapshots or locking.
3. Actor model : each car is an actor that owns its state and communicates by message. This is the natural fit once the system is distributed.

Key rule: the dispatcher reads a snapshot of each car’s state to compute cost. A slightly stale snapshot just means a marginally worse assignment, but it must never produce a corrupted one. Choosing slightly stale reads over heavy locking keeps the call path fast.

7. Edge cases that separate good designs from great ones

• Call for the current floor: if a car is idle at floor 7 and someone presses UP at floor 7, open the doors immediately.
• Duplicate presses: deduplicate by (floor, direction), as shown above.
• Overload: if currentLoad > capacity, hold the doors, sound a buzzer, and ignore new hall-call stops until load drops. A full car should skip hall calls and let other cars take them.
• Door obstruction: a sensor re-opens the doors and resets the timer. Cap the retries, then close slowly with an alarm.
• Starvation: with LOOK, no floor waits more than about two sweeps, but also track max wait time and boost the priority of calls older than a threshold.
• Car fault mid-assignment: all hall calls assigned to a failed car must be reassigned to other cars immediately. Car calls already inside the car are the passengers’ problem, so open doors at the nearest floor.
• Fire/emergency mode: override everything. Recall all cars to the ground floor, open doors, and ignore calls. Safety logic must sit above the dispatcher in the hierarchy.
• Maintenance mode: a car in maintenance accepts no hall calls and is excluded by the dispatcher filter.
• Invalid floors: validate requests against [0, N-1]

8. Scaling the architecture

For a single building, everything above runs in one process. In a real deployment (or a smart-building platform managing many buildings), the architecture looks like this:

Design principles worth stating explicitly:

• Two-tier control. The group controller makes optimization decisions. Each car controller owns safety and motion. If the group controller dies, cars degrade gracefully to autonomous mode (serve their own car calls, answer the nearest hall calls) rather than stopping.
• Safety is never distributed. Door interlocks, overspeed, and emergency braking live in dedicated hardware or firmware on the car, not in software that depends on a network.
• Heartbeats and watchdogs between the group controller and cars. A missed heartbeat marks a car unavailable and triggers hall-call reassignment.
• Event-driven telemetry. Every arrival, door cycle, fault, and call is published to a stream. This feeds dashboards, wait-time metrics, and predictive maintenance (door motors that take progressively longer to close are about to fail).
• Persistence. Persist pending hall calls so a controller restart doesn’t silently drop waiting passengers. Car state can be rebuilt from the cars themselves on reconnect.

9. Testing and simulation

Elevator logic is nearly impossible to validate by hand, so build a simulator early:

1. Deterministic tick clock (as in our tick() design), so tests are fast and reproducible.
2. Traffic generators: replay realistic scenarios such as morning up-peak, lunch, random uniform, and a “burst of 50 people at floor 0”
3. Metrics harness: record average wait, max wait, average ride time, number of stops per trip, and total distance traveled.
4. Strategy comparison: run the same traffic against FCFS, nearest-car, cost-based, and destination dispatch, then compare numbers instead of arguing opinions.
5. Invariant tests: a car never moves with doors open, a car never exceeds its floor range, and every hall call is eventually served (no starvation.)
6. Fault injection: kill a car mid-run and verify its hall calls are reassigned within N ticks

If we can say in an interview, “I’d compare dispatch strategies in a simulator using wait-time percentiles,” we are signaling real engineering maturity.

10. Advanced: smarter dispatching

10.1 Reassignment (dynamic dispatch)

The assignment made at call time is only the best guess at that moment. Conditions change: a car gets a long chain of car calls, or a closer car frees up. Advanced systems re-evaluate pending hall calls every few seconds and move them to a better car if the ETA improves meaningfully (with hysteresis so calls don’t flip-flop).

void reevaluate(HallCall call) {
    ElevatorCar current = call.assignedCar();
    ElevatorCar best    = strategy.select(cars, call);

    int currentCost = cost(current, call);   // recomputed with latest state
    int bestCost    = cost(best, call);

    boolean worthMoving = best != current
            && bestCost + SWITCH_THRESHOLD < currentCost;   // e.g. save at least 5 ticks

    if (worthMoving) {
        current.unassignHallCall(call);   // remove from A's stops
        best.assignHallCall(call);        // add to B's stops
    }
}

10.2 Destination dispatch

Instead of UP/DOWN buttons, passengers enter their destination in the lobby (keypad or app), and the system tells them which car to take (“Go to car C”).

Why this is powerful: the system knows every passenger’s destination before boarding, so it can group passengers going to nearby floors into the same car. The result is fewer stops per trip and noticeably higher throughput, which is why modern skyscrapers use it.

The trade-offs:

• A passenger can’t change their mind inside the car, and the car has no “destination buttons” to fix mistakes.
• Requires a lobby UI, and groups arriving together may be split across cars.
• Harder to model: a request becomes (origin, destination) rather than (floor, direction), which changes the cost function to optimize group trip time.

10.3 Traffic-aware modes and Predictive and learning-based control

Building traffic has strong daily patterns, and good controllers detect and adapt to them:

Idle-car parking is an underrated feature. Where idle cars wait matters. Spreading them evenly (or concentrating at the lobby during up-peak) can cut average wait time significantly without moving a single passenger faster.

With historical call data (time, floor, direction), a model can predict where demand will appear next and pre-position cars. Reinforcement-learning dispatchers have shown wait-time reductions over hand-tuned heuristics in research. The practical path is to train and evaluate offline in a simulator, deploy behind a feature flag, and fall back to the cost-based strategy on any anomaly.

10.4 Zoning, express cars, and sky lobbies

• Zoned groups: in tall buildings, split elevators into banks (low-rise 1–20, high-rise 21–40) so each car makes fewer stops
• Express cars: skip the lower floors entirely for high-rise destinations
• Sky lobbies: passengers transfer at a mid-building lobby. This is a building-level design decision, but the software must model cars with limited floor ranges, so make “floors served” a property of each car.

10.5 Optimization objectives

“Minimize wait time” hides a choice. Common objectives:

• Average waiting time: efficient but can neglect outliers
• Maximum waiting time: fairness-focused
• Sum of squared waiting times: punishes long waits disproportionately, a popular compromise
• Energy use: fewer starts and stops, regenerative braking, parking cars when idle

Production systems often use a weighted cost function combining these, tuned per building.

EPILOGUE

The multi-elevator problem teaches a clean progression:

1. Model the domain by separating hall calls from car calls, and cars from the dispatcher.
2. Make state explicit with a state machine, so safety rules become guards.
3. Pick the right single-car algorithm: LOOK beats FCFS and SSTF.
4. Solve assignment with cost, not distance, since direction, stops, and load all matter.
5. Keep it pluggable with the Strategy pattern, so algorithms are swappable and testable.
6. Design for failure with reassignment, graceful degradation, and safety above scheduling.
7. Upgrade deliberately: reassignment, traffic modes, destination dispatch, and prediction each earn their place only when a measured wait-time problem justifies them.
8. Prove it with a simulator, because intuition about elevators is famously wrong.

PROLOGUE

Every public API eventually meets the same three visitors: the well-behaved client, the buggy client stuck in a retry loop, and the malicious one.

A rate limiter is how we treat all three fairly without letting any of them take the system down. It’s also one of the best system design questions because the naive version takes ten lines and the production version touches algorithms, distributed state, atomicity, and failure modes.

1. What are we building?

A component that decides, for each incoming request, whether to allow it or reject it (typically with HTTP 429 Too Many Requests) based on how many requests the caller has recently made.

Why do we need one?

1. Protect availability: stop one noisy client from starving everyone else
2. Control cost: cap usage of expensive downstream calls (DB, third-party APIs, ML inference)
3. Security: slow down brute-force logins, credential stuffing, scraping
4. Fairness and monetization: enforce plan tiers (free: 100/min, paid: 10,000/min)

Functional requirements

1. Limit requests by a key: user ID, API key, IP address, or a combination
2. Support different limits per endpoint and per plan
3. Return clear feedback to the client (remaining quota, when to retry)

Non-functional requirements

1. Low latency: the check sits on every request, so it should add only a millisecond or two
2. Highly accurate (within reason): not letting through 2x the limit
3. Distributed: works across many app servers
4. Fault tolerant: if the limiter breaks, it must not take the whole API down with it

That last point shapes a lot of later decisions. The rate limiter is a protective component, so it must never become the thing that causes the outage.

2. Where should it live?

A practical pattern is layered limiting: coarse per-IP limits at the edge (cheap protection against floods), plus fine-grained per-user and per-endpoint limits closer to the application, where plan and business context are known.

In a Java backend this might be a servlet Filter or Spring HandlerInterceptor that calls a shared limiter library or service.

3. The algorithms

This is the core of the problem. There are five classic approaches, each with different trade-offs.

Algorithm A: Fixed Window Counter

Divide time into fixed windows (say, one minute). Keep a counter per key per window. Increment on each request. Reject if the counter exceeds the limit.

Window 12:00:00 – 12:00:59 → counter for user42
Window 12:01:00 – 12:01:59 → new counter

Pros: trivial to implement, tiny memory (one integer per key), O(1).

Cons: the boundary burst problem. With a limit of 100/min, a client sends 100 requests at 12:00:59 and another 100 at 12:01:00. That’s 200 requests in two seconds, yet both windows are individually within the limit. The system sees up to 2x the intended rate around the boundary.

Algorithm B: Sliding Window Log

Store the timestamp of every request per key (typically in a sorted structure). On each request:

1. Remove timestamps older than now - windowSize
2. If the remaining count is below the limit, allow and add the new timestamp
3. Otherwise reject

Pros: perfectly accurate, with no boundary problem.

Cons: Memory-hungry. For a limit of 10,000/min, we store up to 10,000 timestamps per user. At millions of users, this gets expensive fast. Rejected requests may or may not be stored, depending on whether we want to penalize hammering.

Algorithm C: Sliding Window Counter

Take algorithm 1, fixed window lengths, but now keep counters for the current and previous fixed windows, then estimate the rolling count with a weighted sum:

estimated = currentWindowCount + previousWindowCount × overlapRatio

If we’re 30% into the current minute, the previous window’s overlap with our rolling window is 70%:

estimated = current + previous × 0.70

Pros: nearly the accuracy of the log approach at the memory cost of the fixed window (two integers per key). It smooths the boundary problem.

Cons: it’s an approximation, assuming requests in the previous window were evenly distributed. In practice, studies of real traffic show the error is very small, and this is why many large systems use it.

Algorithm D: Token Bucket

Picture a bucket that holds up to capacity tokens. Tokens are added at a steady refillRate (say, 10 per second). Each request consumes one token. No token means reject.

capacity = 100, refillRate = 10 tokens/sec

// Idle for a while → bucket fills to 100
// Burst of 100 requests → all allowed instantly
// Then sustained rate limited to 10/sec

Pros:

1. Allows controlled bursts, which matches real client behavior (page loads fire many calls at once)
2. Only two values per key: tokens and lastRefillTime
3. Used by Amazon and Stripe in their public APIs

Cons: two parameters (capacity and refill rate) to tune, and they interact, so reasoning about “what limit did we actually set?” is slightly less intuitive.

The lazy refill trick: we don’t need a background thread adding tokens. Compute them on demand:

public final class TokenBucket {
    private final long capacity;
    private final double refillPerSecond;
    private double tokens;
    private long lastRefillNanos;

    public TokenBucket(long capacity, double refillPerSecond) {
        this.capacity = capacity;
        this.refillPerSecond = refillPerSecond;
        this.tokens = capacity;
        this.lastRefillNanos = System.nanoTime();
    }

    public synchronized boolean tryAcquire() {
        long now = System.nanoTime();
        double elapsedSeconds = (now - lastRefillNanos) / 1_000_000_000.0;
        tokens = Math.min(capacity, tokens + elapsedSeconds * refillPerSecond);
        lastRefillNanos = now;

        if (tokens >= 1) {
            tokens -= 1;
            return true;
        }
        return false;
    }
}

Algorithm E: Leaky Bucket

Requests enter a queue (the bucket) and are processed at a constant outflow rate. If the queue is full, new requests are dropped.

Pros: produces a perfectly smooth output rate, which is ideal when protecting a downstream system that can’t tolerate bursts.

Cons: bursts fill the queue and add latency to legitimate requests. Old requests can starve new ones. It’s more of a traffic shaper than a pure limiter.

Comparison between all 5 Algorithms

A reasonable default is Token Bucket or Sliding Window Counter.

4. The basic design: single server, in-memory

Start simple.

One app server, with a ConcurrentHashMap<String, TokenBucket> keyed by client ID.

Request ─► Filter ─► map.computeIfAbsent(clientId) ─► bucket.tryAcquire()
├─ true → continue
└─ false → 429

This works fine for a single instance. Two problems appear immediately:

1. Memory leak: the map grows forever as new client IDs arrive. We need eviction of idle entries (Caffeine cache with expireAfterAccess is a good fit).
2. It doesn’t survive scale-out. Run three app servers behind a load balancer, and each has its own counters. A client with a limit of 100/min can effectively make 300/min, depending on how the load balancer routes it.

Which brings us to the real problem.

5. Going distributed: shared state in Redis

The standard answer is to move counters to a shared, fast store. Redis is the usual choice: in-memory, sub-millisecond, atomic operations, and built-in key expiry.

The naive implementation and its race condition

A first attempt at a fixed window in Redis:

count = GET user42:12:00 // this notation mean user42 came at 12:00 time block
if count < limit:
    INCR user42:12:00
    allow
else:
    reject

This has a classic check-then-act race. Two servers both GET a count of 99, both see it’s below 100, and both INCR, landing at 101. Under high concurrency the limit leaks.

Fix 1: Use atomic operations (Only for fixed window counter — Algorithm 3A)

For a fixed window counter, INCR is atomic and returns the new value. Increment first, then compare:

Here user42:12:00 is the Redis key: user ID plus the minute-window. Each new minute gets a fresh key.

count = INCR user42:12:00 // this notation mean user42 came at 12:00 time block

// If user came for the first time, that is count 1, 
// expire that time block after 60 seconds
if count == 1: EXPIRE user42:12:00 60

// then comparison logic
if count > limit: 
    reject 
else 
    allow

Putting it together with an example

Limit: 3 requests per minute for an user

12:00:05 request 1 → INCR user42:12:00 → 1 → first one, so EXPIRE 60 → allow
12:00:20 request 2 → INCR user42:12:00 → 2 → allow
12:00:40 request 3 → INCR user42:12:00 → 3 → allow
12:00:50 request 4 → INCR user42:12:00 → 4 → 4 > 3 → reject (429)
12:01:05 (key already auto-deleted by Redis)
12:01:05 request 5 → INCR user42:12:01 → 1 → new window, new key → allow

(Even INCR followed by EXPIRE can leave a key without a TTL if the process dies between them, so prefer a Lua script or SET key 0 EX 60 NX first.)

Fix 2: Lua scripts for multi-step logic (For sliding window and token counter — Algorithm 3B-3E)

For token bucket or sliding window, the logic needs a read, a computation, and a write. Wrap it in a Lua script, which Redis executes atomically on the server with no interleaving from other clients.

-- KEYS[1] = bucket key
-- ARGV[1] = capacity, ARGV[2] = refill/sec, ARGV[3] = now (ms), ARGV[4] = cost
local data = redis.call('HMGET', KEYS[1], 'tokens', 'ts')
local tokens = tonumber(data[1]) or tonumber(ARGV[1])
local ts = tonumber(data[2]) or tonumber(ARGV[3])

local elapsed = math.max(0, tonumber(ARGV[3]) - ts) / 1000
tokens = math.min(tonumber(ARGV[1]), tokens + elapsed * tonumber(ARGV[2]))

local allowed = 0
if tokens >= tonumber(ARGV[4]) then
  tokens = tokens - tonumber(ARGV[4])
  allowed = 1
end

redis.call('HMSET', KEYS[1], 'tokens', tokens, 'ts', ARGV[3])
redis.call('PEXPIRE', KEYS[1], math.ceil(tonumber(ARGV[1]) / tonumber(ARGV[2]) * 1000) * 2)
return { allowed, math.floor(tokens) }

From Java, load it once with SCRIPT LOAD and call it via EVALSHA (Spring Data Redis’s RedisScript, or Redisson’s built-in RRateLimiter, handle this).

Clock caveat: pass now from a consistent source. If each app server uses its own clock, skew between servers corrupts refill math. Either use Redis TIME inside the script or keep servers NTP-synced.

Side-note On Lua :- Lua is a lightweight, high-level, multi-paradigm scripting language designed primarily for embedded use in applications. Lua is heavily used in Redis as its primary embedded server-side scripting language.

6. Rule configuration

Hardcoded limits don’t survive contract with product requirements. Model the rules as data:

rules:
  - id: login-attempts
    match: { endpoint: "POST /auth/login" }
    key: ip
    limit: 5
    window: 60s
    algorithm: sliding_window_counter

  - id: api-free-tier
    match: { plan: free }
    key: apiKey
    capacity: 100
    refillPerSecond: 1.67
    algorithm: token_bucket

  - id: api-paid-tier
    match: { plan: paid }
    key: apiKey
    capacity: 5000
    refillPerSecond: 83
    algorithm: token_bucket

Design points:

1. Store rules in a config service or DB, cached locally on each app server and refreshed periodically (or pushed on change). Limits then change without a deploy.
2. Rule resolution order: most specific match wins (endpoint + plan beats plan alone).
3. Composite keys: rate:{ruleId}:{keyType}:{keyValue}, for example rate:api-free-tier:apiKey:ak_9f2.
4. Multiple limits at once: a request can be checked against several rules (per-second burst limit and per-day quota). Reject if any fails.

7. Telling clients what happened

A good rate limiter is communicative. Return 429 with headers so well-behaved clients can self-regulate:

HTTP/1.1 429 Too Many Requests
Retry-After: 12
RateLimit-Limit: 100
RateLimit-Remaining: 0
RateLimit-Reset: 12
Content-Type: application/json

{ "error": "rate_limited", "message": "Retry after 12 seconds." }

Also send RateLimit-Remaining on successful responses, so clients can slow down before hitting the wall. On the client side, the matching behavior is exponential backoff with jitter, so a thousand throttled clients don’t all retry at the same instant and recreate the spike.

8. Scaling the limiter itself

At large scale, the Redis layer becomes the next bottleneck.

Shard the counters

Partition keys across a Redis Cluster using hash slots. Because every request for one client touches only that client’s key, there are no cross-key operations and sharding is straightforward. Keep each Lua script operating on a single key so it stays within one slot.

Reduce the round trip

The check adds one network hop per request. Ways to trim it:

• Co-locate Redis close to app servers (same region and AZ)
• Connection pooling and pipelining to avoid connection setup cost
• Local pre-filtering: a tiny in-process check rejects obviously abusive clients (already blocked) without touching Redis

Approximate counting with local batching

For extremely high-volume systems, each app server keeps a local counter and syncs to Redis every N requests or every few milliseconds, borrowing a chunk of quota at a time (similar to the range-allocation idea in ID generators).

• Pros: drastically fewer Redis calls
• Cons: the limit becomes approximate. With 50 servers each holding a local allowance, a client can briefly exceed the global limit. This is a deliberate trade of accuracy for latency and throughput, and it’s acceptable when the limit exists for protection rather than billing.

9. Failure modes: fail open or fail closed?

Most systems fail open by default with alerting, since a broken limiter shouldn’t become an outage. But apply fail-closed selectively for security-sensitive endpoints. Mixed policies per rule are completely reasonable.

Some of the supporting measures are :

1. Tight timeouts (a few milliseconds) on the Redis call, so a slow limiter doesn’t add latency to every request.
2. Circuit breaker (Resilience4j in Java) to stop calling Redis during an outage and degrade to a local in-memory limiter as a fallback. That fallback is imprecise but still gives some protection.
3. Redis replication with failover (Sentinel or Cluster). Remember that async replication means a failover can lose a few recent counter updates, which is usually acceptable.

10. Multi-region and global limits

If we run in several regions, there’s a question: is the limit per region or global? Pick based on how strict the guarantee must be.

• Per-region limits: simplest. Each region has its own Redis, with no cross-region latency. A client can use up to limit × regions in total, which is often fine, especially if users are geo-routed to one region anyway.
• Global limits: need cross-region synchronization (expensive and slow) or a split-quota approach: divide the global limit among regions (say 40/40/20 based on traffic share) and rebalance periodically, with each region enforcing its share locally.
• Eventually consistent sync: regions asynchronously exchange usage counts and adjust. Accurate enough for most needs without blocking the request path.

11. Advanced concerns

Identifying the client

• IP address: easy but flawed. Many users share an IP (corporate NAT, mobile carriers), and attackers rotate IPs. Behind proxies, read the real client IP from X-Forwarded-For only from trusted proxies, since the header is spoofable.
• API key / user ID: accurate for authenticated traffic. Apply after authentication.
• Layered approach: IP-based limit pre-auth (to protect the login endpoint itself), user-based limit post-auth.

Request cost weighting

Not all requests are equal. A search query may cost 10x a simple GET. Let rules consume variable tokens (the cost argument in the Lua script above) so limits track actual resource use.

Concurrency limits

Rate (requests per second) differs from concurrency (requests in flight). A slow endpoint can be overwhelmed by few requests that each hold resources for a long time. Add a concurrent request limiter (a semaphore with a TTL) alongside the rate limit.

Load shedding and priority

Under extreme overload, rate limiting per client isn’t enough. Load shedding drops lowest-priority traffic first (for example, shed batch/background traffic before interactive traffic) to keep critical paths alive.

Dynamic and adaptive limits

Limits can respond to system health. If downstream latency climbs or CPU saturates, tighten limits automatically, then relax as the system recovers (similar to TCP congestion control, or Netflix’s adaptive concurrency limits).

Allowlists and blocklists

Trusted internal services bypass limits. Confirmed abusers get blocked outright, ideally at the edge or WAF, so they never consume our limiter’s resources.

12. Observability

A rate limiter we can’t see into is a source of mystery support tickets. Track:

• Allowed vs rejected counts, per rule and per endpoint
• Top throttled keys, to spot abusers and also to find legitimate customers who need a higher plan
• Limiter latency (p50/p95/p99) and Redis error rate
• Fail-open events, which should page someone
• Rule hit distribution, to find rules that never trigger (too loose) or trigger constantly (too tight)

A useful rollout technique is shadow mode (dry run): evaluate a new rule and log what would have been rejected, without actually rejecting. Review the data, tune the thresholds, then enforce. This avoids the classic launch-day incident of accidentally throttling real customers.

13. The Full Architecture Diagram

EPILOGUE

The rate limiter shows how a small idea expands under real constraints:

1. Pick the right algorithm for the traffic: token bucket for bursty public APIs, sliding window counter for smooth general limits.
2. Make the check atomic, because race conditions silently destroy accuracy.
3. Share state through Redis, and shard it when volume demands.
4. Treat failure as a design input: decide fail-open or fail-closed per rule, deliberately.
5. Keep it off the hot path’s critical risk: tight timeouts, circuit breakers, local fallbacks.
6. Make it observable and tuneable, with shadow mode and per-rule metrics.
7. Communicate with clients through 429, Retry-After, and quota headers.

As with most system design, the winning answer isn’t the most elaborate one. A single Redis with token-bucket Lua scripts and a fail-open policy handles an enormous amount of real traffic.

Here is an trade-off summary before concluding!

PROLOGUE

Every system design interview has one question that looks trivial and turns out to be deep: “Design a URL shortener like bit.ly.” It starts as a hashmap and ends up touching ID generation, caching, sharding, analytics, and abuse prevention.

1. What are we building?

A service that does two things:

1. Shorten: take https://example.com/products/very/long/path?utm=abc and return https://sho.rt/aZ3kP9x
2. Redirect: when someone opens https://sho.rt/aZ3kP9x, send them to the original URL

Functional requirements

1. Generate a short, unique link for a long URL
2. Redirect short link to original URL
3. Optional custom alias (sho.rt/my-sale)
4. Optional expiry time
5. Basic click analytics

Non-functional requirements

1. Highly available: a dead redirect means a broken link on someone’s printed poster
2. Low latency: redirects should feel instant (p99 under ~50 ms)
3. Read-heavy: far more redirects than creations
4. Non-guessable (nice to have): people shouldn’t be able to enumerate all links
5. Durable: a link created today should work years from now

Stating these up front matters. Almost every later decision (cache, DB, ID scheme) traces back to “this is a read-heavy, availability-first system.”

2. Before we develop — some GUESSTIMATES

So guesstimate summarization:

1. Write load is tiny, so ID generation doesn’t need to be exotic at first.
2. Read load is moderate but spiky, so caching is the main lever.
3. 3 TB fits on one big machine, but the availability requirement pushes us to replicate and shard anyway.

How long should the short code be?

Using Base62 (a-z A-Z 0-9):

• 6 chars: 6²⁶ ≈ 56 billion
• 7 chars: 6²⁷ ≈ 3.5 trillion

For 6 Billion URLs, 7 characters gives plenty of headroom, and 6 would also work. We’ll go with 7.

3. Lets dive into Basic Design [LEVEL 1]

Let’s start simple with :-

Client ──► App Server ──► Database

POST /api/v1/urls
{
  "longUrl": "https://example.com/a/very/long/path",
  "customAlias": "my-sale",        // optional
  "expiresAt": "2027-01-01T00:00:00Z"  // optional
}
→ HTTP status code 201, with body
{ "shortUrl": "https://sho.rt/aZ3kP9x" }



GET /{shortCode}
→ HTTP status code 302 , with body 
{ "location": "https://example.com/a/very/long/path" }

The database also lets keep very straightforward , because the access pattern is almost purely key to value lookup by short_code. There are no joins and no complex queries!

CREATE TABLE url_mapping (
  short_code   VARCHAR(10)  PRIMARY KEY,
  long_url     TEXT         NOT NULL,
  user_id      BIGINT       NULL,
  created_at   TIMESTAMP    NOT NULL,
  expires_at   TIMESTAMP    NULL
);

Revisiting the access pattern, billions of rows, key-value lookups, minimal relations, and heavy reads.

• NoSQL (Cassandra, DynamoDB) is a natural fit. It scales horizontally and handles simple key lookups at huge scale. Partition key: short_code.
• SQL (MySQL/PostgreSQL) works fine at this scale with sharding and read replicas.

For custom aliases and uniqueness guarantees, a conditional write (INSERT ... IF NOT EXISTS in Cassandra, or a unique constraint in SQL) lets the database enforce uniqueness for us.

4. The heart of the problem: generating the short code

Approach A :- Hash the long URL , simple enough , do a SHA-256 and take first 7 chars. Cons — Collision!

Approach B :- What if we retry on collision? Fair enough, but at 6 billion estimated URLs, we might retry a lot! Also it costs a DB round-trip (both lookup + store)

Approach C :- Counter + Base62 (recommended)

Take a globally unique incrementing integer ID and encode it in Base62. Uniqueness is guaranteed by construction, so collisions are impossible.

public final class Base62 {
    private static final String ALPHABET =
        "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";

    public static String encode(long id) {
        if (id == 0) return "0";
        StringBuilder sb = new StringBuilder();
        while (id > 0) {
            sb.append(ALPHABET.charAt((int) (id % 62)));
            id /= 62;
        }
        return sb.reverse().toString();
    }
}

encode(125) gives "21", and encode(3_500_000_000_000L) is around 7 characters.

The catch: sequential IDs give sequential codes (aaaaab, aaaaac, ...), which are guessable. Fix this by scrambling the ID with a reversible bijection (e.g. multiply by a large odd number modulo 62⁷, or use a Feistel cipher / format-preserving encryption) before encoding. We keep uniqueness and gain obscurity.

5. Making ID generation scale [LEVEL 2]

A single DB auto-increment is a single point of failure and a bottleneck. Here are the options, from simple to robust.

Option 1: Range allocation (Key Range Service)

A small coordination service (backed by ZooKeeper, etcd, or a DB row with optimistic locking) hands out ranges of IDs to app servers.

Server 1 → gets range 1,000,000 – 1,999,999
Server 2 → gets range 2,000,000 – 2,999,999

Each server then generates IDs locally from its range with no network call per request. When a range is exhausted, it asks for a new one.

• Pros: very fast and simple to reason about
• Cons: if a server crashes, the unused part of its range is lost. That’s fine, since we have trillions of IDs to spare.

Option 2: Pre-generated Key Generation Service (KGS)

A separate service pre-generates millions of unique random 7-char keys into a unused_keys table and moves them to used_keys when handed out. App servers fetch keys in batches and cache them in memory.

• Pros: zero collision handling at request time, and keys are naturally random
• Cons: an extra component to run, and we need to handle crashed servers holding unused keys

Option 3: Snowflake-style IDs

A 64-bit ID composed of timestamp | machine ID | sequence. No coordination is needed at runtime.

• Pros: fully decentralized
• Cons: the IDs are large, so the Base62 code comes out at 10–11 characters rather than 7

6. API Redirect status code, which to use, 301 or 302?

For most cases, we will use 302, also if analytics needed, we will use 302. If we want raw speed and the links never change, we will use 301. Most commercial shorteners use 302 (or 307) for this reason.

7. Adding a cache [LEVEL 3]

Since traffic follows a power law (a small number of links get most clicks), caching is hugely effective.

Client ─► Load Balancer ─► App Servers ─► Redis Cache ─► (if missed) ─►Database

Read path (cache-aside):

1. Check Redis for short_code
2. Hit: return the redirect immediately
3. Miss: read from DB, populate Redis with a TTL (asynchronously), return the redirect

Details that matter:

• Eviction: LRU works well for this skewed traffic.
• TTL: set it no longer than the link’s own expires_at.
• Negative caching: cache “not found” results briefly. Otherwise a bot hammering nonexistent codes bypasses the cache and hits our DB every time. (important point in real life system)
• Hot keys: a viral link can overload a single Redis node. Mitigate with a small in-process local cache (e.g. Caffeine in Java) in front of Redis, or replicate hot keys.

With a ~90%+ hit rate, our database sees only a fraction of the 4,000+ reads/sec.

8. Time for Overall Architecture

Why split Write and Redirect services? Their load profiles are completely different (40 req/s versus 4,000+ req/s). Separating them lets us scale, deploy, and fail them independently. A bug in the creation flow should never break redirects.

9. Scaling the database: Sharding

When one DB can’t hold or serve all the data, partition it.

• Hash-based sharding on short_code: even distribution, and lookups know exactly which shard to hit. This is the standard choice.
• Consistent hashing: adding or removing shards moves only a fraction of the keys, avoiding a massive reshuffle.
• Range-based sharding: simple, but sequential codes create hot shards, so avoid it unless codes are scrambled.

Pair sharding with replication (typically 3 replicas per shard) for availability and read scaling.

10. Analytics (Advanced)

A redirect should never wait on analytics writes. Do it asynchronously:

1. Redirect Service responds with the 302 immediately
2. It publishes a click event (short_code, timestamp, IP-derived geo, user-agent, referrer) to Kafka
3. A consumer aggregates the events into an OLAP store (ClickHouse, Druid, or a data warehouse)
4. A dashboard queries pre-aggregated counts (clicks per day, per country, per device)

If the analytics pipeline goes down, redirects keep working. Events queue in Kafka and catch up later. This is the principle of never putting a non-critical dependency on the critical path.

11. Expiry and cleanup

• Lazy deletion: on read, if expires_at has passed, return 404/410 and optionally delete the row.
• Background job: a periodic sweeper removes expired rows in batches (avoid giant deletes that lock tables).
• Cassandra TTL / DynamoDB TTL can handle expiry natively.
• Consider recycling expired codes only if we are running low. With a 7-char space, we usually don’t need to.

12. Security and abuse prevention

A public URL shortener is a favourite tool for phishers, so treat this as a first-class concern.

• Rate limiting per IP and per API key (token bucket in Redis) on the creation endpoint
• Malicious URL checks against Google Safe Browsing or similar, at creation time and periodically afterward
• Input validation: only allow http/https, enforce a max length, and block internal or private IP ranges to prevent SSRF if we ever fetch the URL for previews
• Non-enumerable codes via scrambling, so attackers can’t crawl all links
• Reserved words: block aliases like admin, api, login
• Interstitial warning page for flagged links instead of silently redirecting
• Authentication and authorization for link management (edit, delete, view stats)

13. Reliability and multi-region (Advanced)

• Multi-region deployment with geo-DNS so users hit the nearest region
• Redirect path is read-only, so it replicates easily across regions. Writes can go to a primary region, or each region can own its own ID range to avoid cross-region coordination.
• CDN caching of redirects (when using 301, or 302 with a short Cache-Control) offloads huge traffic for viral links
• Graceful degradation: if the DB is unreachable but the cache is alive, keep serving cached redirects
• Observability: track redirect latency (p50/p95/p99), cache hit ratio, 4xx/5xx rate, DB replication lag, and ID range exhaustion. Alert on cache hit ratio dropping, because it’s an early warning of trouble.

EPILOGUE

A URL shortener teaches the full arc of system design in miniature:

1. Clarify requirements and estimate scale before drawing boxes.
2. Start simple: one server, one table, one lookup.
3. Solve the unique problem (ID generation) properly.
4. Optimize for the dominant workload (reads) with caching.
5. Scale out with sharding, replication, and service separation.
6. Protect the critical path by moving analytics off it.
7. Harden against abuse and failure.

“Production-ready apps in a snap”: Highlights the speed and ease with which it allows developers to build robust, deployable applications.

“Just Run”: Refers to how simple it is to run a Spring Boot application due to the embedded server and minimal setup requirements.

We will use Spring Data JPA for database interaction, Spring Validation for validation handling, H2 Database, and integrate Maven for dependency management.

Step 1: Create a new Spring Boot application

Generate a Spring Boot application using Spring Initializr:

Visit: https://start.spring.io/
Project: Maven
Spring Boot Version: 3.1.X (use latest compatible version)
Dependencies: Spring Web, Spring Data JPA, H2 Database, Validation

Download the project and extract it to IntelliJ.

Step 2: Configure Maven Dependencies (pom.xml)

Open the pom.xml file and verify that the relevant dependencies exist. Run mvn clean install to download all the dependencies.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>customer-management</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>jar</packaging>
    <name>customer-management</name>
    <description>Spring Boot application for customer management</description>
    <properties>
        <java.version>21</java.version>
    </properties>

    <dependencies>
        <!-- Spring boot starter for REST API -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        
        <!-- Spring Boot Starter JPA for database access -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
        </dependency>
        
        <!-- H2 Database -->
        <dependency>
            <groupId>com.h2database</groupId>
            <artifactId>h2</artifactId>
            <scope>runtime</scope>
        </dependency>
        
        <!-- Validation -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-validation</artifactId>
        </dependency>

        <!-- Lombok (for getter/setter annotations) -->
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>

        <!-- Spring Boot DevTools for development -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
            <scope>runtime</scope>
        </dependency>

        <!-- Spring Boot Test -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

Step 3: Configure application.properties

Inside the src/main/resources folder, modify or create the application.properties file to specify database configuration.

# H2 Database configuration
spring.datasource.url=jdbc:h2:mem:testdb
spring.datasource.driverClassName=org.h2.Driver
spring.datasource.username=sa
spring.datasource.password=password
spring.jpa.database-platform=org.hibernate.dialect.H2Dialect
spring.h2.console.enabled=true
spring.h2.console.path=/h2-console

# Show Hibernate SQL
spring.jpa.show-sql=true

Step 4: Create the Entity Layer (Customer.java)

The entity represents a database table. Create a class Customer with necessary annotations.

package com.example.customermanagement.entity;

import jakarta.persistence.*;
import jakarta.validation.constraints.Email;
import jakarta.validation.constraints.NotBlank;
import jakarta.validation.constraints.Size;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;

@Entity
@Table(name = "customers")
@Data
@NoArgsConstructor
@AllArgsConstructor
public class Customer {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY) // Auto-generate primary key
    private Long id;

    @NotBlank(message = "Name is mandatory")
    @Size(min = 2, max = 50, message = "Name must be between 2 and 50 characters")
    private String name;

    @NotBlank(message = "Email is mandatory")
    @Email(message = "Email should be valid")
    private String email;
}

Step 5: Create the Repository Layer (CustomerRepository.java)

This layer interacts with the database. Create an interface that extends JpaRepository

The JpaRepository<Customer, Long> is a fundamental interface in Spring Data JPA that provides sophisticated CRUD (Create, Read, Update, Delete) functionality for the Customer entity, with Long representing the type of the entity's primary key. By extending this interface, we inherit methods for basic data operations as well as pagination and sorting capabilities without needing to implement them.

package com.example.customermanagement.repository;

import com.example.customermanagement.entity.Customer;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.stereotype.Repository;

@Repository
public interface CustomerRepository extends JpaRepository<Customer, Long> {
}

Step 6: Create the Service Layer (CustomerService.java)

package com.example.customermanagement.service;

import com.example.customermanagement.entity.Customer;
import com.example.customermanagement.exception.CustomerNotFoundException;
import com.example.customermanagement.repository.CustomerRepository;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import java.util.List;

@Service
public class CustomerService {

    @Autowired
    private CustomerRepository customerRepository;

    public List<Customer> getAllCustomers() {
        return customerRepository.findAll();
    }

    public Customer getCustomerById(Long id) {
        return customerRepository.findById(id)
                .orElseThrow(() -> new CustomerNotFoundException("Customer not found with ID " + id));
    }

    public Customer createCustomer(Customer customer) {
        return customerRepository.save(customer);
    }

    public Customer updateCustomer(Long id, Customer customerDetails) {
        Customer customer = getCustomerById(id);
        customer.setName(customerDetails.getName());
        customer.setEmail(customerDetails.getEmail());
        return customerRepository.save(customer);
    }

    public void deleteCustomer(Long id) {
        Customer customer = getCustomerById(id);
        customerRepository.delete(customer);
    }
}

Step 7: Create Custom Exception Handling (CustomerNotFoundException.java and GlobalExceptionHandler.java)

@ControllerAdvice is a Spring annotation used for global exception handling, data binding, and model enhancement across multiple controllers. It acts as an interceptor for exceptions thrown by @RequestMapping methods, centralizing error handling logic to avoid repetitive code in individual controllers.

It is commonly used for global @ExceptionHandler methods.

In programming, particularly Java, super(message); is a constructor call used in a subclass to invoke a specific constructor of its immediate parent class, typically passing a string message to initialise the parent with error details or context.

// CustomerNotFoundException.java
package com.example.customermanagement.exception;
public class CustomerNotFoundException extends RuntimeException {
    public CustomerNotFoundException(String message) {
        super(message);
    }
}



// GlobalExceptionHandler.java
package com.example.customermanagement.exception;

import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.ExceptionHandler;

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(CustomerNotFoundException.class)
    public ResponseEntity<String> handleCustomerNotFoundException(CustomerNotFoundException ex) {
        return new ResponseEntity<>(ex.getMessage(), HttpStatus.NOT_FOUND);
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<String> handleGlobalException(Exception ex) {
        return new ResponseEntity<>("Internal server error: " + ex.getMessage(), HttpStatus.INTERNAL_SERVER_ERROR);
    }
}

Step 8: Create the Controller Layer (CustomerController.java)

package com.example.customermanagement.controller;

import com.example.customermanagement.entity.Customer;
import com.example.customermanagement.service.CustomerService;
import jakarta.validation.Valid;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

import java.util.List;

@RestController
@RequestMapping("/api/customers")
public class CustomerController {

    @Autowired
    private CustomerService customerService;

    @GetMapping
    public List<Customer> getAllCustomers() {
        return customerService.getAllCustomers();
    }

    @GetMapping("/{id}")
    public Customer getCustomerById(@PathVariable Long id) {
        return customerService.getCustomerById(id);
    }

    @PostMapping
    public Customer createCustomer(@Valid @RequestBody Customer customer) {
        return customerService.createCustomer(customer);
    }

    @PutMapping("/{id}")
    public Customer updateCustomer(@PathVariable Long id, @Valid @RequestBody Customer customerDetails) {
        return customerService.updateCustomer(id, customerDetails);
    }

    @DeleteMapping("/{id}")
    public ResponseEntity<String> deleteCustomer(@PathVariable Long id) {
        customerService.deleteCustomer(id);
        return ResponseEntity.ok("Customer with ID " + id + " deleted successfully.");
    }
}

Step 9: Run the Application

mvn spring-boot:run

Access the endpoints with tools like Postman

• GET /api/customers
• GET /api/customers/{id}
• POST /api/customers
• PUT /api/customers/{id}
• DELETE /api/customers/{id}

That’s it! We’ve built a complete Spring Boot project with CRUD APIs, validation, and exception handling.

Annotations in Spring Boot indeed revolutionize application development by providing a concise and elegant way to configure and manage applications, eliminating the need for lengthy XML-based configurations.

Benefits of Annotations in Spring Boot

1. Reduce XML-Based Configuration — By using annotations, developers can avoid creating and maintaining verbose applicationContext.xml or other configuration files. For example, annotations such as @SpringBootApplication, @Component, and @Bean allow Spring to perform dependency injection and configuration directly in Java code.
2. Improve Code Readability and Maintainability — Annotations make the code more self-explanatory because configuration logic is tied directly to the relevant Java class or method. For example, @RestController clearly indicates that the annotated class will handle REST API requests.\
3. Enable Auto-Configuration — The @SpringBootApplication annotation simplifies the setup process by leveraging intelligent defaults and auto-configuring components based on the dependencies in the class path. This reduces manual configuration effort significantly.
4. Simplify Dependency Injection — Annotations like @Autowired or @Qualifier allow the framework to wire beans automatically, removing the need for manual wiring. This makes the development process faster and less error-prone.
5. Support Stereotype Annotations — Annotations like @Component, @Service, @Repository, and @Controller clearly define the role of a particular class in the application. This helps to organize the code and align it with standard design patterns.
6. Boost Development Speed — Developers can focus on writing business logic rather than spending time defining bean configurations and dependencies inside XML files.

Core Spring Boot Annotations

1. @ SpringBootApplication

This annotation is used to mark the main class of a Spring Boot application. It encapsulates @SpringBootConfiguration, @EnableAutoConfiguration, @ComponentScan and @Configuration annotations with their default attributes.

@SpringBootConfiguration : Indicates that a class provides configuration for a Spring Boot application.

@EnableAutoConfiguration : Enables Spring Boot’s auto-configuration mechanism, automatically configuring beans based on classpath dependencies and application properties.

@ComponentScan : A spring framework annotation that tells the Spring container to automatically find and register beans (like @Component, @Service, @Repository, @Controller) in specified packages, streamlining configuration by eliminating manual XML bean definitions and promoting convention over configuration in modern Spring apps. It scans base packages and sub-packages, automatically managing eligible classes as beans, often used with @Configuration

@Configuration: Indicates that the class provides Spring configuration and bean definitions. Acts as a replacement for XML-based configuration.

@SpringBootApplication
public class SampleApplication {
    public static void main(String[] args)
    {
        SpringApplication.run(SampleApplication.class, args);
    }
}

2. @ Component

Marks a class as a generic Spring-managed component. Spring automatically detects and registers it during component scanning.

@Component
public class EmailService {
  // ...
}

3. @ Service

Used in the service layer to define business logic and improve code readability. Service annotation is a specialized @Component that indicates the class contains business logic.

@Service
public class UserService {
  // ...
}

4. @ Repository and @ Transactional — Data access related Annotations

Used in the DAO layer to interact with the database. Automatically translates database-related exceptions into Spring exceptions.

@Repository
public class UserRepository {
  // ...
}

The @Transactional annotation is used to manage transactions in Spring, ensuring atomicity (all-or-nothing) and consistency during database operations.

1. Ensures a method runs within a transaction (commit on success, rollback on failure).
2. Commonly used for methods that perform CRUD operations on the database.
3. Can be applied at class or method level.

@Service
public class UserService {
    @Transactional
    public void registerUser(User user) {
        userRepository.save(user);
        emailService.sendWelcomeEmail(user);  // Both operations run in a single transaction.
    }
}

In case of exceptions, changes in userRepository.save() are rolled back automatically.

5. @ Bean

The @Bean annotation is used to define Spring-managed beans inside a @Configuration class. It tells the Spring container to manage the method's return object as a bean, providing it for dependency injection.

1. Explicit Bean Definition: @Bean is used when you manually want to configure a bean and provide it to the Spring Context. It is used in cases where automatic component scanning via annotations (e.g., @Component) is not applicable.
2. Declarative Bean Creation: The annotated method contains the logic to instantiate, configure, and initialize the bean.
3. Custom Configurations: Allows setting dependencies, properties, and custom logic during bean creation.

@Configuration
public class AppConfig {
    @Bean
    public MyService myService() {
        return new MyServiceImpl();  // Manually created and registered service bean
    }

    @Bean
    public MyRepository myRepository() {
        return new MyRepositoryImpl();
    }
}

// IMPORTANT -> myService and myRepository become Spring-managed beans 
// and can be injected into other components using @Autowired.

Benefits of @Bean:

• Greater control over bean creation (e.g., for third-party libraries that don’t use @Component).
• Ideal for defining beans with custom instantiation logic or when automatic scanning isn’t feasible.

Dependency Injection Spring Boot Annotations

Dependency Injection (DI) allows Spring to manage the lifecycle and dependencies of objects (beans) in the application. It ensures loose coupling between components, making code more modular and maintainable. Spring Boot provides several annotations to facilitate DI, including @Autowired, @Qualifier, and @Value.

1. @ Autowired

This annotation is used to inject a bean automatically into a field, constructor, or method. Spring checks the application context and resolves the dependency by type.

@Autowired automatically finds a matching bean by type in the Spring container. It can be used on fields, setters, or constructors.

@Component
public class MyService {
    public void performTask() {
        System.out.println("Task performed!");
    }
}

// FIELD AUTOWIRED INJECTION
@Component
public class MyController {
    @Autowired   // Automatically injects MyService bean
    private MyService myService;

    public void handleRequest() {
        myService.performTask();   // MyService is now available to use
    }
}

// CONSTRUCTOR AUTOWIRED INJECTION
@Component
public class MyController {
    private final MyService myService;

    @Autowired
    public MyController(MyService myService) {  // Constructor injection
        this.myService = myService;
    }

    public void handleRequest() {
        myService.performTask();  // MyService is now available to use
    }
}

2. @ Qualifier

When there are multiple beans of the same type, Spring cannot decide which bean to inject. In such cases, you can use the @Qualifier annotation to specify the exact bean name to inject.

@Component("myServiceImpl1")
public class MyServiceImpl1 implements MyService {
    @Override
    public void performTask() {
        System.out.println("Task performed by MyServiceImpl1!");
    }
}

@Component("myServiceImpl2")
public class MyServiceImpl2 implements MyService {
    @Override
    public void performTask() {
        System.out.println("Task performed by MyServiceImpl2!");
    }
}

@Component
public class MyController {
    // Injecting a specific bean using @Qualifier
    @Autowired
    @Qualifier("myServiceImpl2")
    private MyService myService;

    public void handleRequest() {
        myService.performTask();  // This will use MyServiceImpl2
    }
}

Configuration and Properties Spring Boot Annotations

1. @ Value

This annotation is used to inject externalized configuration values from properties files, environment variables, or system properties into fields, constructors, or methods. Useful for injecting configurations like application settings, URLs, port numbers, etc. Values are fetched from the application.properties or application.yml file, or via environment variables.

// application.properties file
app.name=MySpringBootApp
app.version=1.0.0
app.port=8080


// while usage in a java class
@Component
public class AppConfig {
    @Value("${app.name}") // Inject value from application.properties
    private String appName;

    @Value("${app.version}") // Inject value from application.properties
    private String appVersion;

    @Value("${app.port}") // Inject value from application.properties
    private int appPort;
}

2. @ ConfigurationProperties

The @ConfigurationProperties annotation is used to bind a group of related configuration properties from sources like application.properties or application.yml to a POJO (Plain Old Java Object) in a type-safe manner.

Key Features:

• Binds multiple related configuration properties under a specific prefix.
• Supports externalized configuration retrieval in a clean, structured way.
• Useful for structured or hierarchical configuration.
• Promotes maintainability and readability for configuration properties.

// application.properties file
app.name=MySpringBootApp
app.version=1.0.0
app.port=8080



// JAVA POJO
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;
@Component
@ConfigurationProperties(prefix = "app")
public class AppConfig {
    private String name;
    private String version;
    private int port;

    // Getters and setters
}



// Usage in another Java class
@Component
public class MyService {
    @Autowired
    private AppConfig appConfig;

    public void printConfig() {
        System.out.println(appConfig.getName());
        System.out.println(appConfig.getVersion());
        System.out.println(appConfig.getPort());
    }
}

3. Validation Annotations

Ensure input correctness using annotations.

1. @NotNull: Field must not be null.
2. @NotBlank: String must contain at least one non-whitespace character.
3. @Email: Validates email format.
4. @Size: Restricts length/size of the field.

// Example of the above validations are

public class UserDto {
    @NotNull
    private String username;

    @NotBlank
    private String fullName;

    @Email
    private String email;

    @Size(min = 6, max = 15)
    private String password;

    // Getters and setters
    // .......
}


// Now for the below when UserDto is used as request
// When validation fails, 
// Spring automatically returns a 400 Bad Request with validation errors
@RestController
@RequestMapping("/users")
public class UserController {
    @PostMapping("/register")
    public String register(@RequestBody @Valid UserDto userDto) {
        return "User registered!";
    }
}

Web and REST API Spring Boot Annotations

1. @ RestController

Used to create RESTful web services and automatically returns data in JSON or XML format. Combines @Controller and @ResponseBody for handling REST APIs.

@RestController
public class HelloController {
  // ...
}

2. @ RequestMapping

Maps HTTP requests to controller classes or methods. Defines the base URL path for request handling.

@RequestMapping("/api")
public class ApiController {
  // ...
}

3. HTTP Method Annotations

@GetMapping("/users")
public List<User> getUsers() {
    return userService.getAllUsers();
}

4. @ PathVariable

Extracts values from the URI path and binds them to method parameters.

@GetMapping("/users/{id}")
public User getUser(@PathVariable int id) {
    return userService.getUser(id);
}

5. @ RequestParam

Reads query parameters from the request URL. Used for optional or filtering inputs.

@GetMapping("/search")
public String search(@RequestParam String keyword) {
    return keyword;
}

6. @ RequestBody

Binds the HTTP request body to a Java object. Commonly used with POST and PUT requests.

@PostMapping("/users")
public User saveUser(@RequestBody User user) {
    return userService.save(user);
}

EPILOGUE

Core Spring Boot Annotations: Provide foundational functionality like application setup (@SpringBootApplication) and bean management (@Bean, @Component).

Dependency Injection Spring Boot Annotations: Manage object dependencies via @Autowired, resolve conflicts using @Qualifier, and inject external configuration values with @Value.

Configuration and Properties Spring Boot Annotations: Enable type-safe binding of configuration properties to POJOs with @ConfigurationProperties and declare configuration classes using @Configuration.

Web and REST API Spring Boot Annotations: Facilitate development of REST APIs and web controllers with @RestController, @RequestMapping, @GetMapping, and other HTTP method mappings.

PROLOGUE

“The goal is to turn data into information, and information into insight.” — Carly Fiorina

NumPy, short for Numerical Python, stands as one of the most widely-used Python libraries for numerical computing. Open-source and incredibly versatile, it serves as the backbone for scientific and computational workflows, enabling efficient handling of numerical data. NumPy is a cornerstone tool for performing numerical operations. Its simplicity and performance make complex calculations straightforward, even for beginners.

On the other hand, Pandas is a powerful, open-source Python library designed for data manipulation and analysis. It is built on top of NumPy and provides highly efficient data structures such as DataFrames (2D) and Series (1D) for organizing and analyzing structured data.

Core Features of NumPy

1. N-dimensional Array: At the heart of NumPy lies its powerful N-dimensional array (ndarray). This data structure can hold multi-dimensional numerical data in an efficient and easy-to-access format. It forms the basis of numerical operations, making large-scale manipulation of data seamless.
2. Broadcasting: NumPy simplifies arithmetic operations through broadcasting, allowing calculations between arrays of different shapes without excessive use of loops. This ensures faster computations and cleaner code.
3. Linear Algebra Capabilities: For anyone working with matrices, NumPy offers robust tools for core linear algebra operations, such as dot products, matrix inversions, eigenvalues, and more. Whether it’s basic matrix manipulation or advanced transformations, NumPy has your back.
4. Seamless Integration with Libraries: NumPy works hand-in-hand with advanced libraries like TensorFlow, PyTorch, and pandas, forming the foundation for machine learning, deep learning, and data manipulation workflows

Why Use NumPy?

1. Efficient storage and manipulation of large datasets.
2. Optimized for performance (implemented in C under the hood).
3. More memory-efficient.
4. Easy integration for matrix math and vector operations.
5. Faster computation compared to traditional Python lists.

Numpy Statements

I. Shape and Dimensions:

The .shape attribute provides the size of each dimension, while .ndim gives the total number of dimensions, and type() gives the type of the object.

II. Array Slicing:

Slicing is a powerful feature in NumPy that allows for efficient access and manipulation of specific portions of an array. It works similarly to slicing in Python lists but is far more flexible when dealing with multi-dimensional arrays.

Syntax:
array[start:stop:step]

• start: The starting index (inclusive). Defaults to 0 if omitted.
• stop: The ending index (exclusive).
• step: The step size (optional). Defaults to 1.

For multidimensional arrays, slicing can be done along multiple axes using commas:
array[row_start:row_stop, col_start:col_stop]

Uses of Array Slicing :-

1. Access Subsets: Retrieve specific portions of an array for analysis without changing the original dataset. Example: arr[2:5] retrieves elements from index 2 to 4.
2. Modify Data: Directly alter portions of an array for updates or corrections. Example: arr[2:5] = [10, 11, 12] modifies elements in place.
3. Filter Values: Use conditional slicing to extract values that meet logical conditions. Example: arr2D > 4 generates a boolean mask identifying values greater than 4.
4. Broadcasting: Combine slicing with broadcasting to perform arithmetic operations on specific sections. Example: arr2D[arr2D > 4] += 1 increments all values greater than 4.
5. Negative Indexing: Use negative indices to slice from the end of the array. Example: arr[-3:] gets the last 3 elements.
6. Default Values: Omit start, stop, or step for cleaner slicing. Example: arr[:3] retrieves the first 3 elements.
7. Boolean Masking: Use conditions to filter arrays dynamically. Example: Selecting values greater than 4 with arr2D[arr2D > 4].
8. Copy vs View: Slices return views of the original array. Changes to the slice affect the original array unless explicitly copied using .copy(). Example: arr_slice = arr[2:5].copy() prevents modifications to the original.

III. Array Manipulation Functions :

1. Reshaping Arrays (reshape) -> The total number of elements must match before and after reshaping.
   TIP: Use arr.reshape(-1, x) to automatically compute one dimension based on the size of the array. Like from 1D of 6 elements to 2D, if we do arr.reshape(-1, 3), then -1 tells NumPy to automatically calculate the number of rows based on the total number of elements. In this case, it calculates 6 / 3 = 2, creating a 2x3 array.
2. Flattening Arrays (flatten) -> Converts a multi-dimensional array into a one-dimensional array. Flattened arrays are useful for simplifying data processing tasks.
   TIP: Unlike .ravel(), flatten() always produces a copy of the original array
3. Concatenation (concatenate) -> Combines two or more arrays along a specified axis (rows for axis=0, columns for axis=1)
   TIP: Use np.vstack() and np.hstack() for vertical/axis=0 or horizontal/axis=1 stacking for a simpler interface.
4. Sorting (np.sort) -> Sorts array elements in ascending order. Works on both 1D and multi-dimensional arrays.
   TIP: For multi-dimensional arrays, use np.sort(arr, axis=...) to specify the axis to sort along

IV. Data Creation :

1. Precision Handling: Use dtype=np.longdouble for higher precision computations, but double-check compatibility with other libraries.
2. Controlled Spacing: Use np.linspace with endpoint=False if you want to exclude the stop value.
3. Reproducibility: Set np.random.seed(seed_value) before using np.random to ensure consistent results across runs (useful for debugging and testing).
4. Random Shapes: Use tuple shapes like (m, n) in np.random or np.full to generate arrays efficiently for various dimensions.

V. Mathematics :

1. Broadcasting Rules: Dimensions must be either the same or equal to 1. Use np.newaxis to reshape arrays for broadcasting.
2. Universal Functions: Use NumPy’s built-in math functions (np.sin, np.exp, np.sqrt) for element-wise calculations across arrays.
3. Performance Boost: Vectorize operations for faster computations instead of using Python loops.
4. Matrix Multiplication Shortcut: Use the @ operator for clean syntax: result = A @ B.
5. Aggregations: Use functions like np.sum, np.max, np.mean with axis for row-wise or column-wise calculations.

Core Features of Pandas

Pandas is a powerful and widely-used open-source Python library designed for data analysis and manipulation. Built on top of NumPy, it simplifies handling and processing structured data, making it a staple tool for data scientists, analysts, and developers.

1. Homogeneity v/s Heterogeneity : All elements within a Series must be of the same data type, but DataFrames can contain columns with different data types. Each column, however, is a Series and thus homogeneous within itself.
2. Size Immutability v/s Mutability: Once created, the size of a Series cannot be changed. Elements can be modified, but the number of elements remains constant. DataFrames are size-mutable, meaning rows and columns can be added or dropped.
3. Analogy: Series are similar to a NumPy 1D array with an added index for labeling, whereas DataFrames are similar to a spreadsheet or a SQL table.
4. Vectorized Operations: Both Series and DataFrames excel when performing vectorized operations (applying an operation to an entire Series or column) rather than iterating element-by-element.

Pandas Series

1. Create Series: Use pd.Series() with custom indices for labeled 1D data handling.
   Example: pd.Series([10, 20, 30], index=['a', 'b', 'c']).
2. Access Data: Use .loc for label-based indexing and .iloc for position-based indexing.
   Example: s.loc['b'] or s.iloc[1].
3. Vectorized Operations: Perform operations like s * 2 directly or use .apply() for custom functions.
   Example: s.apply(lambda x: x * 2).
4. Handling Missing Data: Detect (.isna()), drop (.dropna()), or fill missing values (.fillna()).
   Example: s.fillna(0).
5. Filter with Conditions: Use logical conditions to filter data.
   Example: s[s > 20].
6. Statistical Methods: Use .mean(), .sum(), .max() for quick stats or .describe() for a summary.
   Example: s.mean().
7. Change Index: Rename indices or reset them for better organization.
   Example: s.index = ['x', 'y', 'z'] or s.reset_index().
8. Sort Series: Sort by values (.sort_values()) or indices (.sort_index()).
   Example: s.sort_values(ascending=False).
9. String Handling: Perform string operations using .str.
   Example: s.str.upper() or s.str.len().
10. Unique & Frequency: Identify unique values (.unique()) and count frequencies (.value_counts()).
    Example: s.value_counts().
11. Combine Series: Add, subtract, or concatenate Series easily.
    Example: s1 + s2 or pd.concat([s1, s2]).

Pandas Dataframe

1. Create DataFrame: Use pd.DataFrame() with dictionaries, lists, or NumPy arrays.
   Example: pd.DataFrame({'Name': ['Alice', 'Bob'], 'Age': [25, 30]}).
2. Access Data: Use .loc (label-based), .iloc (position-based), or column selection (df['column_name']).
   Example: df.loc[0], df.iloc[1, :], or df['Age']
3. Add or Remove Columns: Add new columns (df['New'] = values) or remove columns (df.drop('column', axis=1)).
   Example: df['Salary'] = [5000, 6000].
4. Filter Rows: Use conditions to filter rows.
   Example: df[df['Age'] > 25]
5. Groupby and Aggregations: Group data using .groupby() and apply aggregation functions like .sum() or .mean().
   Example: df.groupby('Category').sum()
6. Handle Missing Data: Detect (df.isna()), drop (df.dropna()), or fill (df.fillna()) missing values.
   Example: df.fillna(0)
7. Sorting: Sort rows by column values (.sort_values()) or by index (.sort_index()).
   Example: df.sort_values(by='Age', ascending=False).
8. Merge and Join: Merge or join multiple DataFrames using pd.merge() or df.join().
   Example: pd.merge(df1, df2, on='key').
9. Reshape Data: Pivot tables with .pivot(), .pivot_table(), or melt data using .melt().
   Example: df.pivot(index='ID', columns='Category', values='Values').
10. Apply Functions: Use .apply() or .applymap() for custom row, column, or element-wise functions.
    Example: df['Age'] = df['Age'].apply(lambda x: x * 2)
11. Statistical Methods: Use .mean(), .sum(), .max(), .min() across rows or columns (axis).
    Example: df.mean(axis=0)
12. Export Data: Save DataFrame to a file like CSV or Excel.
    Example: df.to_csv('output.csv'), df.to_excel('output.xlsx')

“Juggling is an Illusion… In reality, the balls are being independently caught and thrown in rapid succession… It is actually task switching.” — Gary Keller

PROLOGUE

Multithreading is essential for improving the performance (parallelism) and responsiveness (concurrency) of applications.

By allowing multiple threads to run concurrently, it enables efficient utilization of CPU resources. Performance is enhanced as separate threads can handle tasks like computation, I/O operations, or data processing simultaneously, reducing overall execution time.

For responsiveness, multithreading ensures that time-consuming tasks (e.g., network calls) run in the background, keeping the user interface responsive and smooth. This is critical in modern applications where lag / delay can result in poor user experience.

We don’t need multiple cores to achieve concurrency, even by using a single core and multiple threads, we can acheive concurrency.

==============================================================

Operating System, Process and Threads

When we turn ON our computer, operating system (OS) is loaded from disk/hard drive to Memory. OS is essential system software that manages a computer’s hardware and software resources, acting as an intermediary between the user and the computer’s physical components.

All of our application/files reside inside the disk/hard drive. When we run an application, OS takes the program / application and creates an instance of the program in the memory. That instance is called process / context of the application.

1. Process: A process is an independent program in execution, containing its own memory space, resources, and system context. It can have one or more threads.
2. Threads within a Process: A thread is like a “lightweight process” that shares the same memory and resources of its parent process but has its own execution context (e.g., program counter, stack, and register states). Multiple threads can exist in a single process and execute different parts of the code simultaneously. Threads share global variables but maintain separate stacks.

Stack is a region in memory, where local variables are stored, and passed into function.
Instruction Pointer is address of the next instruction to execute.
Stack + Instruction Pointer is the current state of the thread.

Stack stores Local primitive types, local references.
Heap stores Objects, Class Members, Static variables.

Context Switch — Key Takeaways

1. Context switching is the process where a CPU stops executing one task (a process or thread), saves its current state (its “context”), and loads the saved state of another task to resume its execution, allowing multiple processes to share a single CPU and creating the illusion of multitasking. Context switching is not cheap, and is the price of multitasking (concurrency.)
2. Too many threads — Thrashing, spending more time in management than real productive work.
3. Threads consume less resources than processes.
4. Context switching between threads from the same process is cheaper than context switch between different processes.

==============================================================

Thread Scheduling — Dynamic Priority with Epochs

Dynamic priority is a method of assigning priorities to threads in a way that can change over time based on various factors. It is used in scheduling algorithms to ensure fairness and improve responsiveness by adapting to the system’s state and workload.

Epochs are a scheduling concept often associated with certain operating systems (e.g., older UNIX-like systems). In some scheduling algorithms, time is divided into discrete epochs during which threads are managed according to their priorities.

These two concepts can be combined to create a scheduling system that is both adaptive and organized:

1. Priorities of threads are adjusted dynamically throughout an epoch.
2. At the end of each epoch, the system recalculates thread priorities based on their recent behavior (e.g., CPU usage, I/O activity).
3. A fair allotment of time slices ensures all threads get a chance to execute during each epoch.

This approach balances responsiveness and fairness in scheduling, particularly for systems that manage a wide range of workloads, such as desktop environments or server applications.

==============================================================

Different ways of Thread Implementation in JAVA

1. Extend Thread Class (encapsulates all thread related functions)

class MyThread extends Thread {
    @Override
    public void run() {
        // Code that executes on a new Thread
        System.out.println("Thread is running " + this.getName());
    }
}

public class Main {
    public static void main(String[] args) {
        MyThread thread = new MyThread();
        thread.start();  // Starts the new thread
    }
}

2. Implement Runnable Interface

class MyRunnable implements Runnable {
    @Override
    public void run() {
        System.out.println("Thread is running");
    }
}

public class Main {
    public static void main(String[] args) {
        MyRunnable myRunnable = new MyRunnable();
        Thread thread = new Thread(myRunnable);
        thread.start();  // Starts the new thread
    }
}

3. Using a Lambda Expression (With Runnable)

The following code is end-to-end which prints thread-name, thread-priority, does some task (sleep), and also handles exception.

public class Main {
    public static void main(String[] args) {

        Thread thread = new Thread(() -> {
            try {

                System.out.println("Thread Name: " + Thread.currentThread().getName());
                System.out.println("Thread Priority: " + Thread.currentThread().getPriority());

                // Simulate some task (e.g., sleeping for 10 second)
                Thread.sleep(10000);

                System.out.println("Task completed successfully!");

            } catch (InterruptedException e) {
                // Handle InterruptedException
                System.out.println("Thread was interrupted: " + e.getMessage());
            }
        });

        // Set thread name and priority
        thread.setName("MyCustomThread");
        thread.setPriority(Thread.NORM_PRIORITY + 1); // Slightly higher than normal priority

        // Start the thread
        thread.start();
    }
}

==============================================================

Properties of Threads in JAVA

1. Thread States

Java provides a set of predefined states that describe the lifecycle of a thread. These states are defined in the Thread.State enum, and we can retrieve the thread's current state using thread.getState()

2. Thread Priority

Threads in Java are assigned a priority to suggest their relative importance to the JVM scheduler. The priority is an integer between Thread.MIN_PRIORITY (1) and Thread.MAX_PRIORITY (10), with the default being Thread.NORM_PRIORITY (5)

getPriority() / setPriority(int): Gets or sets the thread's priority.

3. Daemon Threads

By default, threads are non-daemon (i.e., daemon = false). Non-daemon threads (or also referred to as User threads) keep the JVM process alive as long as at least one of them is running. Unless explicitly stopped, if there are unfinished non-daemon threads, the application will keep running indefinitely, even if all other threads (or the main thread) complete.

The Java Virtual Machine (JVM) will not terminate the application as long as there is at least one thread running.

To ensures that the thread runs in the background and terminates when the main thread finishes, set a thread as a daemon using the setDaemon(true) method before starting the thread. Use isDaemon() to check if a thread is a daemon.

4. Thread Lifecycle Functions

5. Join Threads —

The join() method ensures that the main thread (or caller thread) waits until the specified thread completes its execution. This helps in synchronizing multiple threads when the final result depends on the output of predecessor threads.

1. The Thread.join() method is declared to throw an InterruptedException.
2. Since InterruptedException is a checked exception in Java, the compiler will enforce that it is either caught or declared to be thrown by the enclosing method.
3. Therefore, omitting a try-catch block around thread.join() and also not declaring throws in Java will result in a compile-time error.

// Calculate Sum of Powers of Big Integers

import java.math.BigInteger;

public class ComplexCalculation {
    public BigInteger calculateResult(BigInteger base1, BigInteger power1, BigInteger base2, BigInteger power2) {
        BigInteger result;
        /*
            Calculate result = ( base1 ^ power1 ) + (base2 ^ power2).
            Where each calculation in (..) is calculated on a different thread
        */
        
        PowerCalculatingThread thread1 = new PowerCalculatingThread(base1, power1);
        
        PowerCalculatingThread thread2 = new PowerCalculatingThread(base2, power2);
        
        thread1.start();
        thread2.start();
        
        try {
            thread1.join();
            thread2.join();
        } catch (InterruptedException e) {
            System.err.println("Thread interrupted during join: " + e.getMessage());
        }
        
        return thread1.getResult().add(thread2.getResult());
        
    }

    private static class PowerCalculatingThread extends Thread {
        private BigInteger result = BigInteger.ONE;
        private BigInteger base;
        private BigInteger power;
    
        public PowerCalculatingThread(BigInteger base, BigInteger power) {
            this.base = base;
            this.power = power;
        }
    
        @Override
        public void run() {
           /*
           Implement the calculation of result = base ^ power
           */
          for (BigInteger i = BigInteger.ZERO ; i.compareTo(power) < 0 ; ) {
              result = result.multiply(base); 
              i = i.add(BigInteger.ONE);
          }
            
        }
    
        public BigInteger getResult() { return result; }
    }
}

Thread.join(timeout) —

Threads may take unreasonably long time. The method call thread.join(2000) instructs the current thread to wait for the completion of the thread object's execution. The 2000 argument specifies a timeout in milliseconds.

What does setDaemon(true) with join(timeout) do?

When a daemon thread is joined with a timeout, the calling thread will wait for the daemon thread to complete, but only for the specified duration.

If the daemon thread finishes within the timeout, the join() call unblocks.

If the daemon thread does not finish within the timeout, the join() call unblocks, and the daemon thread continues to run in the background. However, because it is a daemon thread, it will not prevent the program from exiting if all other non-daemon threads have finished. This means that even if the daemon thread is still running after the join(timeout) unblocks, it will be automatically terminated when the main program flow (or other non-daemon threads) completes.

6. Thread.interrupt()

The Thread.interrupt() method in Java is used to interrupt a thread and signal that it should stop or take some corrective action, typically when it's performing a blocking operation (e.g., sleeping, waiting). However, interrupt() itself does not stop the thread — it is up to the thread to respond to the interruption gracefully.

==============================================================

Performance in Multithreading — Latency and Throughput

Latency — Generally not reduced by adding more cores since each task’s individual execution time doesn’t change. Exception: If a single task can be split across cores (parallelism), latency decreases.

Throughput — Throughput defines the amount of material or items passing through a system or process. Improves significantly as more cores process more tasks in parallel.

Formulae —

where Eff = efficiency factor (0 < Eff ≤ 1).

Efficiency comes in picture while dividing tasks into threads, this (below pic) is the overhead cost we should always keep in mind. So for small tasks, it’s actually a disadvantage to create threads and running them in parallel.

Let’s say we have N cores (including physical + virtual), if we break a task into threads more than N, it might increase significant latency due to increased overhead, thus no performance benefit. So stick to breaking of threads to max N.

All above discussions are related to Non-blocking calls.

==============================================================

Threadpool in JAVA

A ThreadPool is a collection of pre-initialized threads that manage and execute tasks efficiently. Instead of creating a new thread for every task (expensive), tasks are assigned to reusable threads in the pool.

1. Pre-Allocated Threads: A thread pool consists of a fixed or dynamically adjustable number of threads (N threads).
2. Task Queue: Tasks are submitted to the pool via a task queue.
3. Thread Assignment: Threads pick up tasks from the queue and execute them.
4. Reusable Threads: Once a thread completes a task, it is reused for the next task instead of being destroyed.

Types of Threadpool in Java

1. Fixed Thread Pool

Creates a thread pool with a fixed number of threads. Once all threads are busy, subsequent tasks are queued until a thread becomes available.

import java.util.concurrent.*;

public class FixedThreadPoolExample {
    public static void main(String[] args) {
        ExecutorService executor = Executors.newFixedThreadPool(4); // 4 threads in the pool
        for (int i = 0; i < 10; i++) {
            executor.execute(() -> System.out.println("Task executed by thread: " + Thread.currentThread().getName()));
        }
        executor.shutdown();
    }
}

2. Cached Thread Pool

Creates a thread pool with dynamically growing threads. Threads that are idle for 60 seconds are terminated. If all threads are busy, new threads are created.

ExecutorService executor = Executors.newCachedThreadPool();
// rest program as of above

3. Single Thread Executor

Creates a thread pool with only a single thread. Tasks are executed sequentially (one-by-one) in the order they are submitted.

ExecutorService executor = Executors.newSingleThreadExecutor();

4. Scheduled Thread Pool (Introduced in Java 8)

Creates a thread pool that can schedule tasks to execute after a delay or periodically (repeated execution). Use case -> CRON jobs.

import java.util.concurrent.*;

public class ScheduledThreadPoolExample {
    public static void main(String[] args) {
        ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(2); // 2 threads

        scheduler.schedule(() -> System.out.println("Task executed after 3 seconds"), 3, TimeUnit.SECONDS);

        scheduler.scheduleAtFixedRate(() -> System.out.println("Repeating task every 2 seconds"), 
                                       1, 2, TimeUnit.SECONDS);

        scheduler.scheduleWithFixedDelay(() -> System.out.println("Task executed with a fixed delay of 1 second"), 
                                         1, 1, TimeUnit.SECONDS);
    }
}

5. Work-Stealing Pool (Introduced in Java 8)

Creates a pool of threads using the ForkJoinPool behind the scenes. (even virtual threads uses ForkJoinPool behind the scenes.) Exploits multiple processor cores by dynamically redistributing tasks from busy threads to idle threads (work stealing).

ExecutorService executor = Executors.newWorkStealingPool(); 
// Parallelism based on available cores.

6. Custom ThreadPool (ThreadPoolExecutor)

We can create a customizable thread pool using ThreadPoolExecutor

import java.util.concurrent.*;

public class CustomThreadPoolExample {
    public static void main(String[] args) {
        ThreadPoolExecutor executor = new ThreadPoolExecutor(
            2,           // Core pool size - Minimum threads kept alive
            4,           // Maximum pool size - Max threads allowed
            30,          // Keep-alive time - How long idle threads are kept alive
            TimeUnit.SECONDS, 
            new LinkedBlockingQueue<>(2) // Task queue with capacity of 2
        );

        for (int i = 0; i < 10; i++) {
            executor.execute(() -> System.out.println("Task executed by thread: " + Thread.currentThread().getName()));
        }

        executor.shutdown();
    }
}

==============================================================

Concurrency Challenges and ways to deal with it

Critical Section and Synchronization

A critical section is a part of the code that accesses shared resources (e.g., variables, files) that should not be concurrently modified by more than one thread. Synchronization ensures that only one thread can access a shared resource (or critical section) at a time to prevent data inconsistency or race conditions. It’s a way to control thread interaction.

Atomic Operations in Java

1. Reading and Writing Primitive Types (Except long and double): Operations like reading and writing int, boolean, char, byte, etc., are atomic. Example: int x = 5; or x = y;
2. Reading and Writing References: Reading/writing object references is atomic. Example: Object obj = myObject; Thus all getters and setters of a class is atomic.
3. Atomic Classes in java.util.concurrent.atomic: Classes like AtomicInteger, AtomicLong, AtomicBoolean, AtomicReference provide atomic methods for increment, decrement, update, etc., on variables.
4. Reading and Writing long and double: These are not atomic by default because they are 64-bit and can be read/written in two separate 32-bit operations. But If declared volatile, then the operations on long and double become atomic. When a variable is declared volatile, all threads will read its latest value directly from the main memory (instead of thread-local cache). Even if we are reading long and double from getters of object references, it will still be non-atomic, and thus we need volatile.

A variable with the volatile keyword in programming ensures that any change to it is immediately visible to all other threads, but it doesn't guarantee atomicity because operations like count++ involve multiple steps (read, modify, write), and a thread could be interrupted between these steps, leading to inconsistent results. In essence, volatile ensures that threads see the most up-to-date value of the variable, but it doesn't ensure that a series of operations on that variable occur as a single, indivisible "atomic" unit.

Synchronized Keyword

A data race occurs when two or more threads access the same shared resource (e.g., variable, object) concurrently, and at least one thread modifies the resource without proper synchronization. This results in undefined or inconsistent behavior because the threads can overwrite each other’s operations, leading to unpredictable outcomes. To overcome data race in JAVA, we use Synchronized Keyword :-

// PART A -> use keyword "synchronized" -> for whole of method
public synchronized void wholeMethod() {
    // critical section code
}

// PART B-> use block "synchronized (this) { ... }" -> for part of method
public void partOfMethod() {
    // non - critial section 
    // ...
    // ...
    
    // entering critical section
    // Synchronized block for thread safety
    synchronized (this) {
        // critical section code
    }
    // exit critical section

    // non - critial section 
    // ...
    // ...
}

// PART C-> use keyword "synchronized" with "static" 
// to block class level whole of method
public static synchronized void wholeMethod() {
    // critical section code
}

But note with above, if we are having multiple methods, all with the synchronized keyword as method definition, then if a thread is executing one of the methods, then all the other methods are deprived from using by other threads!

So how to work around above limitation,

That is by using multiple locks, i.e, locks per method. Because Synchronization happens on object level.

class MyClass {

    private final Object lock1 = new Object(); // Lock for method1
    private final Object lock2 = new Object(); // Lock for method2

    public void method1() {
        synchronized (lock1) { // Locking with lock1
            // some critical section code of method1
        }
    }

    public void method2() {
        synchronized (lock2) { // Locking with lock2
            // some critical section code of method2
        }
    }

}

Now for above if ThreadA blocks method1(), then ThreadB would still be blocked for method1(), but ThreadB can access method2().

But as we use multiple locks in our code, a bigger problem awaits for us.

==============================================================

Issue with multiple locks — Deadlock

A deadlock in Java occurs when two or more threads are blocked forever because each thread is waiting for a resource (lock) held by another thread in a circular fashion. Since no thread can proceed, the execution gets stuck, and the program hangs.

How Does Deadlock Occur — All of these below conditions met

1. Mutual Exclusion: At least one shared resource is non-shareable. Only one thread can access it at a time.
2. Hold and Wait: A thread holds one resource and waits to acquire another resource held by another thread.
3. No Preemption: A resource held by a thread cannot be forcibly taken away; it can only be released voluntarily.
4. Circular Wait: A set of threads form a circular chain where each thread waits for a resource held by the next thread in the chain.

Getting rid of Deadlock

So as we see, if all of the four above holds true, deadlock arises. To get rid of deadlock, a simple solution is to get avoid circular wait. Strictly speaking in terms of acquiring locks and releasing them, always hold locks in the same order.

class Shared_Resource_With_Deadlock {
    void method1() {
        synchronized (String.class) {
            // ...
            synchronized (Integer.class) {
                // ...
            }
        }
    }

    void method2() {
        synchronized (Integer.class) {
            // ...
            synchronized (String.class) {
                // ...
            }
        }
    }
}

The (above) is particular situation of Deadlock. To solve that (below) is the correct order to aquire locks. Notice that the order of releasing locks doesn’t matter.

class Shared_Resource_With_NO_Deadlock {
    void method1() {
        synchronized (String.class) {
            // ...
            synchronized (Integer.class) {
                // ...
            }
        }
    }

    void method2() {
        synchronized (String.class) {
            // ...
            synchronized (Integer.class) {
                // ...
            }
        }
    }
}

==============================================================

Reentrant Lock

The ReentrantLock class in java.util.concurrent.locks provides more advanced locking mechanisms compared to the synchronized keyword. It provides better flexibility and offers features like:

• Ability to lock/unlock explicitly.
• Try to acquire a lock with timeout.
• Support for interruptible locking.

class SharedResource {
    private final ReentrantLock lock = new ReentrantLock(); // Lock Object

    public void increment() {
        lock.lock(); // Acquire the lock
        try {
            // critical section code
        } finally {
            lock.unlock(); 
            // Always release the lock in `finally` block
            // Because if the code throws some exceptions, 
            // we still need to unlock the lock.
        }
    }
}

1. tryLock(timeout)

tryLock(timeout) allows the thread to wait for the lock for a specified amount of time before giving up.

import java.util.concurrent.locks.ReentrantLock;
import java.util.concurrent.TimeUnit;

class LockWithTimeoutExample {
    private final ReentrantLock lock = new ReentrantLock();

    public void performTask() {
        try {
            // Waits for 2 seconds to acquire the lock
            if (lock.tryLock(2, TimeUnit.SECONDS)) { 
                try {
                    // Critical section code
                } finally {
                    lock.unlock(); // Release the lock
                }
            } else {
                System.out.println(Thread.currentThread().getName() + " could not acquire the lock.");
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

2. Interruptible Locking -> lockInterruptibly()

lockInterruptibly() allows us to interrupt a thread while it's waiting for the lock. Very useful for implementing the watchDog, i.e, deadlock detection, because by this merhod

import java.util.concurrent.locks.ReentrantLock;

class InterruptibleLockExample {
    private final ReentrantLock lock = new ReentrantLock();

    public void performTask() {
        try {
            lock.lockInterruptibly(); // Allows interruption while waiting for the lock
            try {
                System.out.println(Thread.currentThread().getName() + " got the lock!");
                Thread.sleep(2000); // Simulate some work
            } finally {
                lock.unlock(); // Release the lock
            }
        } catch (InterruptedException e) {
            System.out.println(Thread.currentThread().getName() + " was interrupted while waiting for the lock.");
        }
    }
}

public class InterruptibleLockTest {
    public static void main(String[] args) {
        InterruptibleLockExample example = new InterruptibleLockExample();

        Thread t1 = new Thread(example::performTask, "Thread-1");
        Thread t2 = new Thread(() -> {
            try {
                Thread.sleep(500); // Allow Thread-1 to acquire the lock
                t1.interrupt(); // Interrupt Thread-1 while waiting for the lock
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }, "Thread-2");

        t1.start();
        t2.start();
    }
}

3. Methods like these given by Reentrant Lock can be very handy for testing

4. ReentrantReadWriteLock in JAVA

ReentrantReadWriteLock is a read-write lock that allows a resource to be accessed by multiple threads for reading or a single thread for writing, but not both at the same time. It improves performance in scenarios where reads are more frequent than writes, as it allows concurrent reading by multiple threads while maintaining exclusive access for writes.

Read Lock (readLock):

• Multiple threads can acquire the readLock simultaneously if no thread holds the writeLock.
• Ensures better performance when there are frequent read operations.
• A counter is hold internally which holds how many threads currently holds readLock

Write Lock (writeLock):

• Allows only one thread to acquire the lock at a time.
• Prevents read and write operations from executing concurrently.
• Also no thread can aquire writeLock even there is a single thread currently holding readLock

class SharedResource {
    private int counter = 0;

    private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();

    public void increment() {
        lock.writeLock().lock(); // Acquire write lock
        try {
            counter++;
            System.out.println(Thread.currentThread().getName() + " incremented counter to: " + counter);
        } finally {
            lock.writeLock().unlock(); // Release write lock
        }
    }

    public int getCounter() {
        lock.readLock().lock(); // Acquire read lock
        try {
            System.out.println(Thread.currentThread().getName() + " read counter: " + counter);
            return counter;
        } finally {
            lock.readLock().unlock(); // Release read lock
        }
    }
}

==============================================================

Semaphores

A Semaphore is a synchronization mechanism in Java that controls access to a shared resource with a fixed number of permits. It is part of the java.util.concurrent package and helps manage concurrent thread access to limited resources (e.g., database connections, thread pools, files).

A semaphore regulates access using a set number of permits. Threads acquire a permit before accessing the resource and release the permit when done. If no permits are available, the thread is blocked until a permit is released.

• Counting Semaphore — Maintains a count of available permits.
• Binary Semaphore — Acts like a lock with only one permit.

Fair Semaphore

By default, Semaphore is unfair, meaning threads waiting to acquire permits may not get them in the order they requested.

To enforce fairness:

Semaphore semaphore = new Semaphore(3, true); // Create a fair semaphore
// This ensures that threads acquire permits in a first-come-first-served (FIFO) order.

Use Cases of Semaphores

1. Database Connection Pool — Limiting concurrent database connections to a fixed number.
2. Thread Pool — Restricting the number of threads that can run simultaneously.
3. Resource Management — Managing access to a limited pool of resources (e.g., files, services).
4. Concurrent Workflows — Controlling order of execution or allowing staged threads to execute periodically.

Key difference between Semaphore and ReentrantLock

Code example of Semaphores

class SharedResource {
    private final Semaphore semaphore = new Semaphore(5); // Allow 5 permits (threads)

    public void accessResource(String threadName) {
        try {
            System.out.println(threadName + " trying to acquire a permit...");
            semaphore.acquire(); // Acquire a permit
            System.out.println(threadName + " got a permit!");

            // Simulate critical section
          
            System.out.println(threadName + " done with the resource.");
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            System.out.println(threadName + " releasing the permit.");
            semaphore.release(); // Release the permit
        }
    }
}

FAQs on Semaphore

1. Can we have negative semaphore value? -> NO
2. Can we have semaphore value as 0 and then release() -> YES. It means previously no permits are currently available, but once released, it will become 1, making a permit available for a waiting process or thread.

==============================================================

Inter-thread Communication in Java

Condition Variables

A condition variable allows a thread to wait until a specific condition is met without busy-waiting. Other threads can signal it when the condition becomes true, allowing the waiting thread to proceed.

Benefits of Condition Variables

1. Fine-grained control: Use multiple Condition objects with a single lock to manage different conditions (e.g., notFull and notEmpty).
2. Readable and Flexible: Easier to design complex thread interactions compared to wait/notify.
3. Avoids Unnecessary Wakeups: Only the appropriate threads are signaled.
4. Condition Variables are especially useful in scenarios like producer-consumer problems, reader-writer locks, or threads needing access control over shared resources.

Producer-Consumer Problem Using Condition Variables

The producer-consumer problem is a classic example of inter-thread communication where:

• The producer thread produces items and adds them to a shared buffer.
• The consumer thread consumes items from the shared buffer.

Condition variables are used to ensure:

1. The producer waits if the buffer is full.
2. The consumer waits if the buffer is empty.

import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
import java.util.LinkedList;

class SharedBuffer {
    private final LinkedList<Integer> buffer = new LinkedList<>();
    private final int capacity = 5;

    // Lock and condition variables
    private final Lock lock = new ReentrantLock();
    private final Condition notEmpty = lock.newCondition(); // For consumer
    private final Condition notFull = lock.newCondition();  // For producer

    // Producer method
    public void produce(int value) throws InterruptedException {
        lock.lock(); // Acquire the lock
        try {
            // Wait until the buffer has space
            while (buffer.size() == capacity) {
                System.out.println("Producer waiting, buffer is full...");
                notFull.await(); // Wait for space
            }
            buffer.add(value);
            System.out.println("Produced: " + value);
            notEmpty.signal(); // Signal the consumer that the buffer is not empty
        } finally {
            lock.unlock(); // Release the lock
        }
    }

    // Consumer method
    public void consume() throws InterruptedException {
        lock.lock(); // Acquire the lock
        try {
            // Wait until there is something to consume
            while (buffer.isEmpty()) {
                System.out.println("Consumer waiting, buffer is empty...");
                notEmpty.await(); // Wait for items
            }
            int value = buffer.removeFirst();
            System.out.println("Consumed: " + value);
            notFull.signal(); // Signal the producer that the buffer is not full
        } finally {
            lock.unlock(); // Release the lock
        }
    }
}

public class ProducerConsumerUsingCondition {
    public static void main(String[] args) {
        SharedBuffer buffer = new SharedBuffer();

        // Producer thread
        Thread producer = new Thread(() -> {
            int value = 0;
            try {
                while (true) {
                    buffer.produce(++value);
                    Thread.sleep(500); // Simulate production time
                }
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });

        // Consumer thread
        Thread consumer = new Thread(() -> {
            try {
                while (true) {
                    buffer.consume();
                    Thread.sleep(1000); // Simulate consumption time
                }
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });

        producer.start();
        consumer.start();
    }
}

Using Objects as Inter-thread Communication in Java

Before the introduction of the java.util.concurrent package (which includes Condition), thread communication in Java was typically implemented using objects themselves as condition variables. The Object class in Java provides built-in methods for thread intercommunication:

1. wait():Causes a thread to wait until it is awakened by another thread. Thread releases the lock on the object and enters a waiting state.
2. notify() — Wakes up one thread that is waiting on the object’s monitor (if any).
3. notifyAll() — Wakes up all threads that are waiting on the object’s monitor.

Every object in Java has a monitor. When a thread wants to communicate, it can call wait(), notify(), and notifyAll() on the object while holding its monitor lock (inside a synchronized block). Threads must hold the intrinsic lock of the object before calling these methods. Otherwise, a runtime exception (IllegalMonitorStateException) will be thrown.

Key Difference Between Using Objects and Condition Variables as Inter-thread Communication in Java

==============================================================

Thread per task model v/s Thread per core model with Blocking I/O

Blocking I/O is a programming concept where an application’s execution halts and waits for an input/output (I/O) operation to complete before proceeding, effectively “blocking” the thread. In this synchronous model, the program’s flow pauses until the I/O operation (like reading a file or receiving network data) finishes and the data is ready for use.

Virtual Threads in Java

Virtual threads revolutionize concurrency in Java by enabling developers to execute millions of lightweight threads without the memory overhead and scalability issues of traditional platform threads (OS threads).

They maintain the familiar thread-based API while addressing the inefficiencies of the traditional thread-per-task model.

1. Lightweight — Virtual threads are much lighter than OS threads and use far less memory.
2. Managed by JVM — Unlike platform threads managed by the OS, virtual threads are managed by the Java runtime.
3. Non-blocking I/O — Blocking calls (e.g., I/O operations) inside virtual threads do not block the underlying OS threads.
4. Rich API — Virtual threads use the familiar Thread class and APIs, making it simple to adopt.
5. Scalable Concurrency — Can scale to millions of simultaneous threads, enabling massive parallelism without excessive overhead.
6. Task Isolation — Virtual threads provide logical isolation for tasks using the same high-level programming model as threads.

How Virtual Threads Work

• Virtual threads run on a small number of carrier platform threads (provided by the OS).
• The JVM scheduler dynamically assigns virtual threads to carrier threads.
• When a virtual thread is suspended (e.g., during a blocking operation), the carrier thread becomes free to run other tasks.
• This makes virtual threads ideal for workloads involving blocking I/O or many short-lived tasks.

Code example

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class VirtualThreadsAPIServer {
    public static void main(String[] args) {
        
        // Create a virtual thread executor
        ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();

        // Simulate handling 10,000 incoming requests
        for (int i = 1; i <= 10_000; i++) {
            int requestId = i;

            // Submit each request as a task to the virtual thread executor
            executor.submit(() -> handleRequest(requestId));
        }

        // Shutdown the executor gracefully after all requests are processed
        executor.shutdown();
    }

    
    private static void handleRequest(int requestId) {
        // Simulate handling an API request
    }
}

Virtual Threads v/s Platform Threads

Performance Benefits using Virtual Thread

1. Virtual threads consume a few kilobytes per thread instead of megabytes, enabling the JVM to handle millions of concurrent threads. Their lightweight nature allows highly-concurrent systems (e.g., API servers, microservices) to scale to massive workloads without hitting resource limits.
2. Virtual threads do not block carrier threads (the limited pool of OS threads backing virtual threads). If a virtual thread is suspended while waiting for I/O (e.g., Thread.sleep() or database calls), the carrier thread is freed for other tasks.
3. Virtual threads allocate memory for their stacks dynamically, using a few kilobytes when idle and growing only when executing tasks that require larger stacks.
4. Virtual threads reduce the CPU overhead caused by excessive thread context-switching, improving throughput and responsiveness.

Note that, if the task only has CPU related calls, and NO blocking I/O, Virtual threads won’t give NO performance benefit.

==============================================================

EPILOGUE

Thanks for your patience reading. Clap if you liked the article.Follow me here, in GitHub and Linked-in. Stay happy and safe.

Would like to end this article with this quote by Brian Goetz —

“It is far easier to design a class to be thread-safe than to retrofit it for thread safety later.”

“The ratio of time spent reading (code) versus writing is well over 10 to 1 … (therefore) making it easy to read makes it easier to write.”― Robert C. Martin

PROLOGUE

1. Platform Independence -> once we have the .jar (Java ARchive) file, which is a package file format used to aggregate multiple Java class files, associated metadata, and resources into a single file for distribution and deployment, we can take it and run it at any Operating Systems. A JVM, or Java Virtual Machine, is a program that enables computers to run Java code. It acts as an intermediary between the Java code (bytecode) and the underlying hardware and operating system, allowing Java to be platform-independent.
2. Object Orient Language -> An object is essentially a self-contained entity that bundles together data (attributes) and the operations (methods) that can be performed on that data. These objects are often created based on blueprints called classes.

JDK v/s JVM v/s JRE — Summary

JVM is the engine that executes Java bytecode, the JRE (Java Runtime Environment) provides the runtime environment to run Java applications by including the JVM and necessary libraries, and the JDK (Java Development Kit) is the comprehensive toolkit for developing Java applications, including the JRE and development tools.

JDK contains JRE which in turn contains JVM.

C++ v/s JAVA

1. C++ is NOT platform independent, whereas Java is.
2. Java doesn’t support multiple inheritance (multi parent class, one base), where as C++ supports it.
3. Java automatically does garbage collection, whereas C++ programmer has to do memory management, i.e, remove object from memory.
4. C++ we have concepts of pointers (access to internal memory). Java doesn’t have such concept.

INDEX

1. JAVA — Wrapper Classes , Autoboxing, and Castings
2. String, StringBuffer, and StringBuilder in Java
3. Object Oriented Programming with deep dive on Inheritance
4. Interface and Abstract Class
5. Constructor , super() , this()
6. Modifiers in JAVA
7. Some Advance Concepts in JAVA — 
   InstanceOf operator , Coupling , Cohesion, Inner Class, Static Inner Class, Generic, Varargs, Garbage Collector, Serialization and Deserialization, Static and Members Initializer Block
8. Exception Handling

JAVA — Wrapper Classes , Autoboxing, and Castings

Wrapper classes in Java are used to provide object representation for primitive types.

Reasons why we need wrapper classes :-

1. NULL is a possible value.
2. Use it in a collection.
3. Methods that support Object creation from other types.

Integer num = new Integer(10); // Integer num wrapper over int value 10
Integer num = new Integer("123"); // Integer wrapper over string value "123"

Autoboxing: Automatically converts a primitive type into its corresponding wrapper class object. And it’s reverse is called unboxing.

Integer num = 456; // Possible due to Autoboxing

Integer numWrapper = new Integer(10); 
numWrapper++; 
// Again possible due to Unboxing and Autoboxing.
// i.e, initially numWrapper converts to primitive number, 
// does the calculation,
// and again Autoboxing to corresponding wrapper class.

Autoboxing helps in saving memory by re-using already created wrapper objects.

// wrapper objects created using new are NOT same object
Integer nineA = new Integer(9);
Integer nineB = new Integer(9);
System.out.println(nineA == nineB); // false
System.out.println(nineA.equals(nineB)); // true


// BUT , with autoboxing, it is the same object
Integer nineC = 9;
Integer nineD = 9;
System.out.println(nineC == nineD); // true
System.out.println(nineC.equals(nineD)); // true

With primitive wrapper classes,

1. equality operator (==) checks for reference equality
2. .equals() method in the Integer class checks for value equality

Implicit Casting (Widening) -> Automatic conversion from a smaller data type to a larger data type (lower precision to higher precision).
byte → short → int → long → float → double

int myInt = 42;
double myDouble = myInt;  // int to double automatically
System.out.println("Implicit Casting: " + myDouble);  // Output: 42.0

Explicit Casting (Narrowing) -> Manual conversion from a larger data type to a smaller data type (higher precision to lower precision).

double myDouble = 99.99;  // double is larger than int
int myInt = (int) myDouble;  // Explicit casting (double -> int)
System.out.println("Integer value after casting: " + myInt);  // Output: 99


double largeValue = 123.456;  
int truncatedValue = largeValue;  // ERROR
// COMPILATION ERROR , we need to manually declare explicit casting        

String, StringBuffer, and StringBuilder in Java

Once String wrapper object is created, it cannot be modified.

That is, String objects are immutable. Modifications like concatenation or replacement create a new String object instead of modifying the existing one.

String str = "value1";
String str2 = str.concat(" value2");
System.out.println("str : " + str);   // value1
System.out.println("str2 : " + str2); // value1 value2

Now if we write String str = “value1”, then this value will be stored in a “String constant pool” — which is inside the Heap memory. If compiler finds a String literal, it checks if it exists in the pool. If it exists, it is reused. Else, created. So use String only when value doesn’t changes much.

Or if we write it as String str = new String(“value1”) always a new object is created.

String str1= "Value1";
String str2 = "Value2" ;
for (int i = 0; і < 100000; ++i) {
  str1 = str1 + str2;
}

// NEVER USE "concat" or "+" on String wrapper objects inside loops, 
// because every time a new Object is created

Solution of above, use StringBuffer. StringBuffer allows the modification of strings without creating new objects. StringBuffer is designed to be thread-safe as its methods are synchronized, making it suitable for multi-threaded environments. StringBuffer not only saves memory, but also gives a very good performance on above issue.

StringBuffer str = new StringBuffer("Hello");
str.append(" World");  // Modifies the same object
System.out.println(str);  // Output: Hello World

Like StringBuffer, StringBuilder is also mutable and allows string modifications. But StringBuilder is not synchronized, meaning it is not thread-safe. It’s the preferred choice for single-threaded applications when string modification is required.

StringBuilder str = new StringBuilder("Hello");
str.append(" World");  // Modifies the same object
System.out.println(str);  // Output: Hello World

Object Oriented Programming

Class — Blueprint | Object — Instance | State of Object — Current Object data

Every class in Java is a sub class of the class Object. That’s why we get methods like toString() or hashCode() or equals() out of the box for each class / wrapper class.

Interesting points :-

1. We can override the toString() and other Object class methods to give our custom implementation.
2. equals() is same as == while comparing two custom class objects. Note that they compare objects, not values, thus :-

Client client1 = new Client(25);
Client client2 = new Client(25);
Client client3 = client1;

//client1 and client2 are pointing to different client objects.
System.out.println(client1 == client2); //false
System.out.println(client1.equals(client2)); //false

//client3 and client1 are pointing to same client objects
System.out.println(client3 == client1); //true
System.out.println(client3.equals(client1)); //true

We can override the equals() method to check for the content comparison.

Inheritance

Inheritance is a mechanism in Java where one class (subclass/child class) can acquire the properties and methods of another class (superclass/parent class). It promotes code reuse and establishes a hierarchical relationship between classes.

public class Actor {
    public void performs(){
        System.out.println("Just Acting");
    };
}

//IS-A relationship. Hero is-a Actor
public class Hero extends Actor {
    public void performs(){
        System.out.println("Acting with Fighting");
    };
}

//IS-A relationship. Comedian is-a Actor
public class Comedian extends Actor {
    public void performs(){
        System.out.println("Acting With Comedy");
    };

    public void makesPeopleLaugh(){
        System.out.println("Yes");
    };
}

// A super class reference variable can hold object of sub class
Actor actor1 = new Comedian(); 
Actor actor2 = new Hero();

actor1.performs(); // Acting With Comedy
actor2.performs(); // Acting with Fighting
// Both above is example of Polymorphism

actor1.makesPeopleLaugh(); // BUT this throws COMPILATION ERROR
// why?? because actor1 is created based on instance of Actor class

// How to fix?
// Cast actor1 to the Comedian type to access the performComedy() method
((Comedian) actor1).makesPeopleLaugh();

In above example, we can see a super class reference variable can hold object of sub class, like actor1 holding Comedian().

Overloading —

1. Defining multiple methods with the same name but different parameter lists (signature).
2. Inheritance not required, can occur within the same class.
3. Works with both static and instance methods.
4. Static polymorphism (compile-time).

class Overloading {
    void print(int num) {
        System.out.println("Number: " + num);
    }
    void print(String text) {
        System.out.println("Text: " + text);
    }
}

Overriding —

1. Redefining a method from the superclass in the subclass to provide a specific implementation.
2. Inheritance is required, occurs between a superclass and subclass.
3. Only works with instance methods. Static methods cannot be overridden (they are hidden).
4. Dynamic polymorphism (runtime).

// Overriding example

class Parent {
    void message() {
        System.out.println("Message from Parent");
    }
}

class Child extends Parent {
    @Override
    void message() {
        System.out.println("Message from Child");
    }
}

Interface and Abstract Class

Interface

In Java, an interface is a reference type that is somewhat similar to a class, but it is used to specify a contract that a class must follow.

Interface is used for defining a contract without imposing structure. Example :-

java.util.Comparator -> Provides a way to define custom comparison logic for objects, enabling sorting with different criteria. Classes implementing Comparator provide the implementation for the int compare(T o1, T o2); method.

java.lang.Runnable -> Defines the contract for a task that can be executed in a separate thread. Classes implementing Runnable provide the implementation for the run() method.

Key Characteristics of Interfaces:

1. Abstract Methods:
   Interfaces can contain method declarations without any implementations (prior to Java 8, all methods in an interface were abstract). All methods are implicitly abstract.
2. Default Methods:
   Since Java 8, interfaces can have methods with default implementations using the default keyword. These provide a default implementation for methods that implementing classes can either use or override.
3. Static Methods:
   Since Java 8, interfaces can also have static methods. Cannot be overridden by implementing classes. Their implementation is fixed within the interface. Also they are called using InterfaceName.staticMethod()
4. Constant Fields:
   All fields in an interface are implicitly public, static, and final. They behave like constants.
5. No Constructors:
   Interfaces cannot have constructors or instance variables.
6. Multiple Inheritance:
   A class can implement multiple interfaces, which allows Java to achieve multiple inheritance indirectly.
7. Visibility:
   A method of an abstract class can have any visibility.

// Example of a complex interface having both static and default methods

public interface Vehicle { // Implicitly public and abstract
    void start(); // Abstract method (Implicitly public and abstract)
    
    default void stop() {
        System.out.println("Stopping the vehicle...");
    }
    
    static void service() {
        System.out.println("Servicing the vehicle...");
    }
}

public class Car implements Vehicle {
    @Override
    public void start() {
        System.out.println("The car starts...");
    }
}

public class Main {
    public static void main(String[] args) {
        Car myCar = new Car();
        myCar.start();       // Calls overridden method
        myCar.stop();        // Calls default method from interface
        Vehicle.service();   // Calls static method from interface
    }
}

Few points on interface :-

1. Interface can extend another Interface.
2. All methods have to be public.
3. All fields in an interface are implicitly public, static, and final. They behave like constants.
4. Class DON’T extend multiple interfaces (common mistake while saying,) But it can IMPLEMENT multiple interfaces.

Abstract Class

In Java, an abstract class is a class that cannot be instantiated directly and is meant to be subclassed.

Abstract Class is used for base classes with shared structure and behavior.

An example of an abstract class in the JDK is AbstractMap, which is part of the Collections Framework. Its subclasses (which include HashMap, TreeMap, and ConcurrentHashMap) share many methods (including get, put, isEmpty, containsKey, and containsValue) that AbstractMap defines.

Key Characteristics of Abstract Class:

1. Cannot Be Instantiated:
   We cannot create an instance of an abstract class directly using the new keyword.
2. Abstract Methods:
   Abstract methods are methods that do not have any implementation and are declared using the abstract keyword. Subclasses must override and provide implementations for abstract methods. Abstract methods should always be inside some abstract class or interface, not within normal class, which will result in compilation error.
3. Concrete Methods:
   Abstract classes can also contain fully implemented (concrete) methods.
4. Constructors:
   An abstract class can have constructors, and these constructors are called when a subclass object is created.
5. Fields:
   Abstract classes can define fields (both static and instance variables) that subclasses can inherit.
6. Inheritance:
   Abstract classes are typically part of an inheritance relationship where other classes extend them.

public abstract class Animal {
    // Abstract method
    abstract void makeSound();

    // Concrete method
    void sleep() {
        System.out.println("The animal is sleeping...");
    }
}

public class Dog extends Animal {
    @Override
    void makeSound() {
        System.out.println("The dog barks.");
    }
}

public class Cat extends Animal {
    @Override
    void makeSound() {
        System.out.println("The cat meows.");
    }
}

public class Main {
    public static void main(String[] args) {
        Animal dog = new Dog();
        Animal cat = new Cat();

        dog.makeSound();  // Output: The dog barks.
        dog.sleep();      // Output: The animal is sleeping.

        cat.makeSound();  // Output: The cat meows.
        cat.sleep();      // Output: The animal is sleeping.

        Animal animal = new Animal(); // COMPILATION ERROR 
       // as abstract class cannot be directly Instantiated 
    }
}

When to use Interface v/s when to use Abstract Class?

Abstract classes can have both abstract and concrete methods, while interfaces only define abstract methods. Abstract classes can also have fields (variables), whereas interfaces can only have constants (static final fields). Interfaces are better suited for defining contracts that unrelated classes can implement, while abstract classes are more for building inheritance hierarchies with shared functionality.

Constructor , super() , this()

Constructors

In Java, a constructor is a special type of method that is used to create and initialize an object of a class.

Key Features of Constructors :-

1. Same Name as Class
2. No return type , not even void
3. They are invoked automatically when an object is created.
4. Default Constructor: A no-argument constructor that is automatically provided by Java if no other constructors are defined.
5. Parameterized Constructor: A constructor that accepts arguments to initialize fields with specific values.
6. Constructor Overloading: Having multiple constructors with the same name but different parameters in a class. This provides flexibility to create objects in multiple ways.
7. Copy Constructor: A copy constructor creates a new object by copying the values from an existing object. Though Java does not provide a built-in copy constructor, you can define one manually in your class by accepting another object of the same class as a parameter.

public class Student {
    String name;
    int age;

    // Parameterized constructor
    public Student(String name, int age) {
        this.name = name;
        this.age = age;
    }

    // Copy constructor
    public Student(Student other) {
        this.name = other.name;
        this.age = other.age;
    }

    public void display() {
        System.out.println("Name: " + name + ", Age: " + age);
    }

    public static void main(String[] args) {
        // Parameterized constructor is called
        Student s1 = new Student("Alice", 22);

        // Copy constructor is called
        Student s2 = new Student(s1); // Copy values from s1 to s2
    }
}

Things to note about copy constructor (difference with C++)

In Java, when an object is passed by value into a function, or return from a function, a copy of the reference to that object is created and passed to the function. This means that both the original variable and the parameter inside the function point to the same object in memory.

Therefore, a copy constructor is not called in this scenario. Java does not have the concept of a “copy constructor” in the same way C++ does, where a new object is created and initialized from an existing one when passed by value.

In Java, objects are always passed by reference value, or object returns by returning a reference to the object, meaning the value of the reference itself is copied.

super()

The super() keyword is used in a subclass constructor to call the constructor of its superclass. If no super(...) call is made, Java implicitly calls the no-argument constructor of the superclass.

class Animal {
    Animal() {
        System.out.println("Animal constructor is called.");
    }
}

public class Dog extends Animal {
    Dog() {
        super(); // Even not provided, Implicit call will happen to Animal constructor
        // also if explicitly provided, 
        // super() should be the first line, else COMPILATION ERROR
        System.out.println("Dog constructor is called.");
    }

    public static void main(String[] args) {
        Dog d = new Dog();
    }
}

// OUTPUT :-
// Animal constructor is called.
// Dog constructor is called.

this() for Constructor Chaining

this() can be used to call another constructor of the same class. This is useful for constructor chaining to avoid code duplication.

public class Student {
    private String name;
    private int age;

    // Default constructor
    public Student() {
        this("Unknown", 0); // Calls parameterized constructor with default values
    }

    // Parameterized constructor
    public Student(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public void display() {
        System.out.println("Name: " + name + ", Age: " + age);
    }

    public static void main(String[] args) {
        Student s1 = new Student(); // Calls default constructor
        Student s2 = new Student("Alice", 22); // Calls parameterized constructor

        s1.display(); // Output: Name: Unknown, Age: 0
        s2.display(); // Output: Name: Alice, Age: 22
    }
}

Modifiers in JAVA

Access Modifier

Final

1. Final Variable — A final variable is a constant. Once initialized, its value cannot be changed during the entire lifetime of the program.
2. Final Method — A method declared as final cannot be overridden in a subclass. This ensures the method's behavior remains fixed when the class is inherited.
3. Final Class — A final class cannot be extended (inherited). This is useful when you want to prevent inheritance to ensure that the class remains immutable or its functionality cannot be altered.

Static Variables:

A static variable is shared across all instances of a class. It belongs to the class itself, not to individual objects, meaning there is only one copy of the static variable for the class, no matter how many objects of the class are created.

1. Shared across all instances of a class.
2. Memory is allocated only once, at the time of class loading.
3. Can be accessed using the class name (e.g., ClassName.staticVariable) without needing to create an object of the class.
4. Typically used for constants or values that need to be shared among all instances of a class.

public class StaticVariableExample {
    static int counter = 0; // Static variable shared by all instances

    public StaticVariableExample() {
        counter++; // Increment counter for every object created via constructor
    }

    public static void main(String[] args) {
        System.out.println("Initial counter: " + StaticVariableExample.counter);

        StaticVariableExample obj1 = new StaticVariableExample();
        StaticVariableExample obj2 = new StaticVariableExample();

        System.out.println("Counter after creating two objects: " + StaticVariableExample.counter);
    }
}

Static Methods:

A static method belongs to the class, not the instances of the class. It can be called directly using the class name without creating an object of the class.

1. Can directly access static variables but not non-static (instance) variables or methods (since instance data requires an object for access).
2. Cannot use this or super keywords, as they are tied to object instances.
3. Typically used for utility or helper methods that perform operations not tied to specific objects.

Why Use Static Variables and Methods?

1. Memory Efficiency: Static variables are stored in a special area called the class area of memory and are initialized only once, reducing memory consumption.
2. Shared States: Static variables act as global variables within the class, helping maintain shared states.
3. Utility Functions: Static methods are great for utility functions that do not depend on instance data (e.g., Math.pow() or Math.sqrt()).

Some Advance Concepts in JAVA

InstanceOf operator

The instanceof operator is used in programming to check if an object is an instance of a specific class or subclass, or if it implements a particular interface.

// SYNTAX :-
object instanceof ClassName

1. object: The reference to the object you want to check.
2. ClassName: The class or interface you want to compare the object against.

instanceof returns a boolean value true if the object is an instance of the class or a subclass of the class, or if the object implements the specified interface.

Use cases of InstanceOf :-

1. Type Checking for Down-casting: Used to ensure that an object belongs to a particular type before performing a downcast.
2. Polymorphism: When dealing with a hierarchy of classes, we can use instanceof to determine the actual type of an object at runtime.
3. Implementing Custom Logic: In scenarios involving multiple object types, instanceof helps execute specific logic based on the object's type. Although, polymorphism or overriding methods is preferred over instanceOf. For example, rather than checking the object's type explicitly and then executing logic, we can design your classes such that the logic is encapsulated within overridden methods.

Coupling

Coupling is the measure of how much one module relies on another. Low coupling means modules are independent and can function without heavily depending on others, making the system more flexible and easier to maintain.

Low coupling is for separation (modules interact minimally).

Cohesion

Cohesion is the measure of how closely related and focused the functionalities within a single module are. High cohesion means the module performs a specific, well-defined task, improving clarity, reusability, and maintainability.

High cohesion is for focus (modules do one thing well).

Inner Class

An Inner Class is a non-static class defined inside another class. It is tightly bound to the instance of its enclosing (outer) class.

1. Requires an instance of the outer class.
2. Can access both static and instance members of outer class.
3. Tightly coupled with outer class instance.
4. Use Cases like — When a class logically belongs within another class (e.g., iterators, helpers, etc.) Or for implementing scenarios where the inner class works on data from the outer class instance.

class OuterClass {
    private String outerField = "Outer Field";

    class InnerClass {
        void displayOuterField() {
            System.out.println(outerField); // Access outer class's private field
        }
    }

    void createInner() {
        InnerClass inner = new InnerClass();
        inner.displayOuterField();
    }
}

public class Main {
    public static void main(String[] args) {
        OuterClass outer = new OuterClass();
        outer.createInner(); // Output: Outer Field
    }
}

Static Inner Class

A Static Inner Class is declared within an outer class but does not require an instance of the outer class to work. It works like an independent static member.

1. Does NOT require an instance of outer class.
2. Can access only static members of outer class.
3. Use Cases like — Independent behavior, utility functions.

class OuterClass {
    private static String staticField = "Static Field";

    static class StaticNestedClass {
        void displayStaticField() {
            System.out.println(staticField); // Access outer class's static field
        }
    }
}

public class Main {
    public static void main(String[] args) {
        OuterClass.StaticNestedClass nested = new OuterClass.StaticNestedClass();
        nested.displayStaticField(); // Output: Static Field
    }
}

Generics

Generics provide flexibility by allowing you to define a class, interface, or method without specifying an exact data type upfront, and later you can specify the type when using them, by using type parameters.

Generics ensure that the data you work with is strongly typed at compile time, reducing the chances of runtime errors.

Commonly defined using T, E, K, V, etc. (e.g., T for Type, E for Element, K for Key, V for Value) but we can use any other valid identifier.

// TYPE 1 :- Generic class definition
class Box<T> { // 'T' is the type parameter
    private T value;

    public void set(T value) {
        this.value = value;
    }

    public T get() {
        return value;
    }
}

// TYPE 2:- Generic method definition
public static <T> T[] returnArray(T[] data) {
    return data;
}

// TYPE 3:- Generic Interface definition
interface Container<T> {
    void add(T item);
    T remove();
}

Also we can restrict a Generic to a particular subset of types by extends.

class MyListRestricted<T extends Number> {
  // 
  // 
}

// now if we declare T as String, throws Compilation Error.

Variable Arguments in Java — Varargs

Variable Arguments (varargs) in Java allows us to pass a variable number of arguments of the same type to a method. Instead of defining a method with a fixed number of parameters, we can use varargs to accept zero or more arguments of the specified type.

Note : We should always define ONLY the last parameter of a method as varargs, else it will throw compilation error! Use ... to define varargs.

Real-life example — Logs / String.format()

String formatted = String.format("Hello, %s! You have %d new messages from %s!", "Peter", 5, "Tony Stark");

// The String.format() method is defined with varargs
public static String format(String format, Object... args);

Garbage Collection

Garbage Collection is a name given to automatic memory management in Java. Aim of Garbage Collection is to Keep as much of heap available (free) for the program as possible. JVM removes objects on the heap which no longer have references from the heap.

Programmatically, we can request (it’s just a request — Not an order) JVM to run Garbage Collection by calling System.gc() method.

JVM might throw an OutOfMemoryException when memory is full and no objects on the heap are eligible for garbage collection.

Serialization and Deserialization

Serialization in Java is the process of converting an object into a byte stream. This byte stream can then be stored (e.g., in a file or database) or transferred (e.g., over a network). Serialization makes it possible to save and later reconstruct an object’s state.

The reverse process — converting a byte stream back into an object — is called Deserialization.

Important points —

1. Usage: Implement the java.io.Serializable interface to the class.
2. Use transient keyword to mark fields that should NOT be serialized.
3. Static fields are NOT serialized because they are class-level variables (not instance-level).
4. Inheritance: If the superclass is not Serializable, the subclass can still be serialized, but the state of the superclass will not be serialized.
5. Deep Serialization: Objects containing references to other objects will serialize their dependencies as well, provided all dependent objects are also Serializable.

Static and Member Initializer Blocks

1. Static Initializer Block — Executes once at the time of class loading, before any object is created. Used for initialization logic for static variables or configurations.
2. Instance Initializer Block — Executes each time we create an object, before the constructor runs.

class Example {
    static int staticValue;

    int instanceValue;

    // Static initializer block
    static {
        staticValue = 42;
        System.out.println("Static Block Executed. staticValue = " + staticValue);
    }

    // Instance initializer block
    {
        instanceValue = 100;
        System.out.println("Instance Block Executed. instanceValue = " + instanceValue);
    }

    // Constructor
    public Example() {
        System.out.println("Constructor Executed");
    }
}

public class Main {
    public static void main(String[] args) {
        Example obj1 = new Example();
        Example obj2 = new Example();
    }
}

// OUTPUT :- 
Static Block Executed. staticValue = 42
Instance Block Executed. instanceValue = 100
Constructor Executed
Instance Block Executed. instanceValue = 100
Constructor Executed

Exception Handling

Exception Handling in Java is a mechanism to handle runtime errors and maintain program flow.

Error v/s Exception

Error is used in situations when there is nothing a programmer can do about an error. Ex: StackOverflowError, OutOfMemoryError.

Whereas exception is used when a programmer can handle the exception.

In Java, Throwable is the superclass of all errors and exceptions. It forms the root of the exception hierarchy, meaning all other exception and error classes in Java inherit directly or indirectly from Throwable

Checked Exceptions:

1. Exceptions checked at compile-time. The compiler checks for the handling or declaration of these exceptions, and a compilation error will occur if they are not addressed.
2. Example: IOException, SQLException
3. Checked exceptions are typically subclasses of the java.lang.Exception class, but not java.lang.RuntimeException
4. Must be handled using try-catch, i.e, if the exception occurs, control is transferred to a corresponding catch block, where we can implement logic to recover from the error / or else log it.
5. Also if don’t want to handle the exception ourselves, we can take alternative actions using throws. It informs the callers of the method that they need to handle these exceptions, either via try-catch blocks or by propagating them further using throws

Design pattern used in Exceptions is Chain Of Responsibility pattern.

public void readFileFromDB() { 
    try {
        // Code that might throw an IOException or SQLException or Exception
    } catch (IOException | SQLException exception) {
        // Code logic what to do when exception happens
        log.error(exception);
    } catch (Exception exception) {
        // NOTE :- Specefic exception should be above generic exceptions
        // That is if we reverse the order, it would give COMPILATION ERROR
        log.error(exception);
    } finally {
        // Final block - always runs
        // Only case when Final block doesn't runs if JVM crash - system.exit()
        // Or some exception block within Final block itself
    }   
}


OR


public void readFileFromDB() throws IOException, SQLException, Exception { 
    // It enable us not to act on it by having a Try-Catch
    // Rather inform callers of the method that they need to handle these
}

Unchecked Exceptions:

Unchecked exception are exceptions that are not checked at the compile time. In Java, exceptions under Error and RuntimeException classes are unchecked exceptions, everything else under throwable is checked.

Unchecked exceptions, are generally considered to indicate programming errors that should ideally be prevented through proper coding practices rather than caught and handled at runtime.

Example like :- ArithmeticException, NullPointerException

Custom Exceptions:

We can define our own exception class by extending Exception or RuntimeException , to throw exceptions due to custom logic.

Also the piece of code which will throw the exception, we need to declare it as throws Exception if it is a Checked exception.

// Custom exception class
class CustomException extends Exception {
    public CustomException(String message) {
        super(message); // Pass the error message to the Exception class
    }
}

public class Main {
    public static void main(String[] args) {
        try {
            validateAge(15); // Test with invalid age (less than 18)
        } catch (CustomException e) {
            System.out.println("Caught Exception: " + e.getMessage());
        }
    }

    // Method that throws the custom exception
    // Declare throws CustomException as it is a checked exception
    public static void validateAge(int age) throws CustomException {
        if (age < 18) {
            throw new CustomException("Age must be 18 or above!");
        }
        System.out.println("Age is valid!");
    }
}

EPILOGUE

Thanks for your patience reading. Clap if you liked the article.

Follow me here, in GitHub and Linked-in. Stay happy and safe. Keep reading and remember one thing, “If you can solve something in some way, there is always a better way to solve it.”

When learning something new, it is actually much harder to unlearn a bad practice first!

PROLOGUE

Before functional programming, most development relied heavily on imperative programming paradigms, where the focus was on step-by-step instructions and mutable state. This often led to complex, error-prone code, as managing state and debugging side effects in large systems became challenging. Concurrency was harder to handle due to race conditions caused by shared mutable data. Code reusability and modularity were limited, making systems harder to maintain and evolve.

Imperative Programming

1. Step-by-step approach: Focuses on how to do things.
2. Mutability: Variables can be updated or changed during execution.
3. Control flow: Focuses on loops, conditional statements, and explicit instructions.
4. Advantages: Efficiency for simple tasks, Better hardware utilisation, More intuitive for newcomers
5. Disadvantages: Error-prone, Less reusable code, Verbose

import java.util.Arrays;
import java.util.List;

public class ImperativeProgramming {
    public static void main(String[] args) {
        List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
        for (Integer number : numbers) {
            if (number % 2 == 0) {
                System.out.println(number);
            }
        }
    }
}

Functional Programming

1. Declarative approach: Focuses on what to do rather than how to do it.
2. Immutability: Values once created cannot be changed.
3. Control flow: Uses streams
4. Higher-order functions: Functions can take other functions as arguments or return them.
5. Lazy evaluation: Computation is delayed until the result is required.
6. Parallel execution: Improving performance.
7. Advantages: Modular Code, Ease of testing, Predictable
8. Disadvantages: Performance overhead, Steep learning curve, Limited tools

import java.util.Arrays;
import java.util.List;

public class FunctionalProgramming {
    public static void main(String[] args) {

        List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

        numbers.stream() // Streams
                .filter(number -> number % 2 == 0) // Lambda function
                .forEach(System.out::println); // Method Reference
    }
}

Deep dive within Streams

Streams — Intro and Initialization

Streams, introduced in Java 8, provide a powerful abstraction for processing sequences of data in a functional and declarative style. They allow operations on data without mutating the original source while supporting lazy evaluation, parallel processing, and concise code.

A stream can be initialized from a lot of data, like collections, arrays, or custom data. Below is the different types of Stream Initialization

import java.util.List;
import java.util.stream.Stream;

public class DifferentTypesOfStreamInitialization {
    public static void main(String[] args) {
        
        // Type 1 :- From a Collection like List, Set, Map - .stream()
        List<Integer> list = List.of(1, 2, 3, 4, 5);
        Stream<Integer> streamFromList = list.stream();

        // Type 2 :- From an Array - Arrays.stream()
        String[] names = {"John", "Jane", "Jack"};
        Stream<String> arrayStreams = Arrays.stream(names);

        // Type 3 :- Directly using Stream.of() to create stream
        Stream<String> streamFromValues = Stream.of("Java", "Streams", "Example");

        // Type 4 :- Infinite Stream using Stream.generate() or Stream.iterate()
        Stream<Integer> infiniteStream = Stream.iterate(0, n -> n + 1);
        infiniteStream.limit(5).forEach(System.out::println);

        // Type 5:- Using Stream.builder() to generate dynamically / runtime
        Stream<String> builderStream = Stream.<String>builder()
                                           .add("Apple")
                                           .add("Banana")
                                           .build();
        builderStream.forEach(System.out::println);

        // Type 6:- Create streams from optional
        Optional<String> optional = Optional.of("Hello!");
        Stream<String> optionalStream = optional.stream();
        optionalStream.forEach(System.out::println); // Output: Hello!

        // Type 7:- Other initialization includes stream from files, 
        // empty streams, and streams from primitive values
        
    }
}

Streams — Intermediate and Terminal Operations

Intermediate operations transforms or filters a stream, and it’s output is another stream. It is lazy by nature, it doesn’t invokes until and unless it is called by a terminal operation. Below code example has all sorts of intermediate operations we can use on streams.

import java.util.*;
import java.util.stream.*;

public class StreamWithNumbers {
    public static void main(String[] args) {
        // List of numbers to process
        List<Integer> numbers = Arrays.asList(10, 20, 30, 40, 50, 20, 60, 70, 80, 10, 90);

        // Unified stream pipeline applying all intermediate operations
        Stream<Integer> processedStream = numbers.stream()
            .filter(num -> num % 20 == 0)                         // Filter values
            .map(num -> num / 10)                                 // Transform each number
            .flatMap(num -> Stream.of(num, num * 2))              // Generate two values: number and number * 2
            .distinct()                                           // Remove duplicates
            .sorted()                                             // Sort numbers in natural order
            .peek(num -> System.out.println("Current : " + num))  // Debugging
            .skip(2)                                              // Skip the first 2 numbers
            .limit(3)                                             // Limit to 3 numbers
            .takeWhile(num -> num < 10)                           // Take numbers while they are < 10
            .dropWhile(num -> num < 5);                           // Drop numbers while they are < 5

        System.out.println("\nFinal Output After All Intermediate Operations:");
        processedStream.forEach(System.out::println);
    }
}

// ACTIVITY FOR READERS -> 
// what would be stream after every intermediate step 
// and what is the final output?

Terminal operations are used to process the elements and produce results, either by consuming the stream data or collecting it. This comprehensive code includes operations such as forEach, toArray, collect, reduce, count, min, max, findFirst, findAny, anyMatch, allMatch, and noneMatch.

import java.util.*;
import java.util.stream.*;
import java.util.function.*;

public class StreamTerminalOperations {
    public static void main(String[] args) {

        // List of numbers as the base dataset
        List<Integer> numbers = Arrays.asList(10, 20, 30, 40, 50, 60, 70, 80, 90, 100);

        // 1. forEach - Perform an action for each element in the stream
        numbers.stream().forEach(num -> System.out.print(num + " ")); // Output: 10 20 30 40 50 60 70 80 90 100

        // 2. toArray - Convert the stream into an array
        Integer[] numberArray = numbers.stream().toArray(Integer[]::new);
        System.out.println(Arrays.toString(numberArray)); // Output: [10, 20, 30, 40, 50, 60, 70, 80, 90, 100]

        // 3. collect - Collect the elements to a data structure (List, Set, Map, etc.)
        List<Integer> collectedList = numbers.stream().collect(Collectors.toList());
        System.out.println(collectedList); // Output: [10, 20, 30, 40, 50, 60, 70, 80, 90, 100]

        // 4. reduce - Reduce the stream into a single value (sum in this case)
        Integer sum = numbers.stream().reduce(0, Integer::sum);
        System.out.println(sum); // Output: 550

        // 5. count - Count the number of elements in the stream
        long count = numbers.stream().count();
        System.out.println(count); // Output: 10

        // 6. min - Find the smallest element
        Optional<Integer> minValue = numbers.stream().min(Integer::compareTo);
        minValue.ifPresent(System.out::println); // Output: 10

        // 7. max - Find the largest element
        Optional<Integer> maxValue = numbers.stream().max(Integer::compareTo);
        maxValue.ifPresent(System.out::println); // Output: 100

        // 8. findFirst - Find the first element
        Optional<Integer> firstValue = numbers.stream().findFirst();
        firstValue.ifPresent(System.out::println); // Output: 10

        // 9. findAny - Find any element (useful in parallel streams)
        Optional<Integer> anyValue = numbers.stream().findAny();
        anyValue.ifPresent(System.out::println); // Output: (Could be any number from the list)

        // 10. anyMatch - Returns true if any element matches the condition
        boolean anyMatch = numbers.stream().anyMatch(num -> num > 50);
        System.out.println(anyMatch); // Output: true

        // 11. allMatch - Returns true if all elements match the condition
        boolean allMatch = numbers.stream().allMatch(num -> num > 0);
        System.out.println(allMatch); // Output: true

        // 12. noneMatch - Returns true if no elements match the condition
        boolean noneMatch = numbers.stream().noneMatch(num -> num < 0);
        System.out.println(noneMatch); // Output: true
    }
}

Streams — Important Notes

1. Streams DO NOT store data, they process data on the fly, thus they are very memory efficient, making it process large dataset!
2. Streams are lazy, they are not invoked during any intermediate operations, i.e, they are only executed when a terminal operation is called.
3. Streams are immutable, they do not modify on the original data. Instead after all the processing, we can call collect to collect the stream into a collection. So immutability ensures functional purity and avoids side effects.
4. Streams can have N number of intermediate operations, but only one terminal operation.
5. Streams cannot be reused, if a terminal operation is called, we cannot call the same stream with another terminal operation, instead we need to create another stream from the original data.
6. Parallel Streams -> As streams are stateless, i.e, no shared data, it is easy to run streams in parallel for better performance.

Either create a parallel stream, which splits the data and processes elements in parallel.

Stream<Integer> parallelStream = numbers.parallelStream();

Or if we have an existing sequential Stream, we can process the data in parallel with

numbers.stream()
       .parrallel()
       .forEach(System.out::println);

Deep dive within Functional Interfaces and Lambdas

In Java, lambda functions (or lambda expressions) enable developers to pass code as data. They are especially useful for functional programming tasks and simplifying code, often reducing boilerplate when implementing interfaces with a single abstract method (such interfaces are called functional interfaces).

Functional Interfaces are the core component of the Java Functional Programming Approach

SYNTAX :- 
(arguments comma-separated) -> { body / code block }

EXAMPLE :-
num -> num % 20 == 0

Functional Interfaces in Java

A functional interface is any interface that contains only one abstract method. To ensure that an interface is a functional interface, you can explicitly annotate it with @FunctionalInterface .

Let’s have a deep dive in one of the functional interface that the Java provides out-of-the-box.

Predicate<Integer> isEven = x -> x % 2 == 0; 
System.out.println(isEven.test(4)); // true

Now the above is the lambda function that we use, the background Java Functional Interface definition of Predicate is as follows :-

@FunctionalInterface
public interface Predicate<T> {
    /**
     * Evaluates this predicate on the given argument.
     *
     * @param t the input argument
     * @return true if the input argument matches the predicate, otherwise false
     */
    boolean test(T t);

    // Other default methods for composition (e.g., and(), or(), negate())
}

The lambda x -> x % 2 == 0 is shorthand for implementing the test() method in the Predicate interface. Behind the scenes, this is equivalent to writing:

public class IsEven implements Predicate<Integer>() {
    @Override
    public boolean test(Integer x) {
        return x % 2 == 0;
    }
};

In Java, the creation of a lambda expression involves both compile-time and runtime processes:

Compile-Time:

1. The compiler performs type checking and infers parameter and return types based on the target functional interface.
2. Instead of creating a dedicated class for the lambda, it generates an invokedynamic instruction and a metadata "recipe" for constructing the lambda at runtime.
3. The lambda’s body is placed in a private static or instance method of the enclosing class.

Runtime:

1. When the invokedynamic instruction is executed, the JVM uses the LambdaMetafactory to dynamically generate a lightweight class implementing the functional interface.
2. The LambdaMetafactory links the invokedynamic call site to the method containing the lambda's body, creating the instance of the lambda dynamically.

In short, the compiler prepares the structure for the lambda, and the JVM dynamically generates and instantiates the lambda at runtime using the LambdaMetafactory

Common Built-in Functional Interfaces in Java

The java.util.function package provides several built-in functional interfaces for common use cases:

1. Predicate: Represents a boolean-valued function, i.e, tests a condition. (same example as above)
2. Consumer: Represents an operation that accepts a single input and returns no result.

Consumer<String> print = s -> System.out.println(s);
print.accept("Hello, Java!"); // Hello, Java!

The functional interface of Consumer is as follows :-

@FunctionalInterface
public interface Consumer<T> {
    /**
     * Performs this operation on the given argument.
     *
     * @param t the input argument
     */
    void accept(T t);

    // Other default methods for composition like "andThen"
}

Thus our lambda s -> System.out.println(s) would be same as below :-

public class Print implements Consumer<Integer>() {
    @Override
    public void accept(String str) {
        System.out.println(s);
    }
};

3. Function : Represents a function that accepts one argument and produces a result.

Function<Integer, String> convertToString = x -> "Number: " + x;
System.out.println(convertToString.apply(10)); // Number: 10

The functional interface of Function is as follows :-

@FunctionalInterface
public interface Function<T, R> {
    /**
     * Applies this function to the given argument.
     *
     * @param t the input argument
     * @return the function result
     */
    R apply(T t);

    // Other default methods for composition like "andThen" and "compose"
}

Thus our lambda x -> "Number: " + x would be same as below :-

public class ConvertToString implements Function<Integer, String>() {
    @Override
    public String apply(Integer x) {
        return "Number: " + x;
    }
};

4. Supplier: Represents a function that supplies a value without taking any input.

Supplier<String> supplier = () -> "Hello, Java!";
System.out.println(supplier.get()); // Hello, Java!

5. Other Functional Interfaces that comes out of the box are like BiFunction (two input, one output), BiPredicate (two input, boolean output), UnaryOperator (one input, specialization of function, where the input and output types are the same) , BinaryOperator (two inputs, specialization of function, where the input and output types are the same), BiConsumer (two inputs, no output), etc.

6. While using Primitive data types, for better performance, directly use IntBinaryOperator instead of BinaryOperator, and same like IntPredicate, IntFunction, IntConsumer, etc. And similarly for Double and Long.

Summary of Functional Programming using Streams, Lambdas with In-built Java Functional Interfaces

import java.util.*;
import java.util.function.*;
import java.util.stream.*;

public class FunctionalProgramming {
    public static void main(String[] args) {

        List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

        // Predicate: Check if a number is even
        Predicate<Integer> isEven = n -> n % 2 == 0;

        // Function: Convert a number to a formatted string
        Function<Integer, String> formatNumber = n -> "Number: " + n;

        // Consumer: Print a string
        Consumer<String> print = System.out::println;

        // Use Predicate with filter(), Function with map(), and Consumer with forEach()
        numbers.stream()
               .filter(isEven)                // Filter even numbers
               .map(formatNumber)             // Convert numbers to strings
               .forEach(print);               // Print each formatted string
    }
}

Or for another extended example

import java.util.*;
import java.util.function.*;
import java.util.stream.*;

public class GenericExample {
    public static void main(String[] args) {

        List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

        Predicate<Integer> isEven = n -> n % 2 == 0;                    
        Function<Integer, String> evenFormatMapper = n -> "Even: " + n;  
        Consumer<String> print = System.out::println;                  
        processStream(numbers.stream(), isEven, evenFormatMapper, print);


        Function<Integer, String> oddFormatMapper = n -> "Odd: " + n;
        Predicate<Integer> isOdd = n -> n % 2 != 0;
        processStream(numbers.stream(), isOdd, oddFormatMapper, print);
    }

    /**
     * Generic processing method to filter, map, and consume using higher-order functions.
     * 
     * @param <T> Type of input elements
     * @param <R> Type of output elements after mapping
     * @param stream       Input stream
     * @param filterLogic  Predicate for filtering stream elements
     * @param mapLogic     Function for mapping stream elements
     * @param consumeLogic Consumer for consuming mapped elements
     */
    public static <T, R> void processStream(
        Stream<T> stream,
        Predicate<T> filterLogic,
        Function<T, R> mapLogic,
        Consumer<R> consumeLogic
    ) {
        stream.filter(filterLogic)     // Apply filtering logic
              .map(mapLogic)           // Apply mapping logic
              .forEach(consumeLogic);  // Apply consuming logic
    }
}

EPILOGUE

Functional programming enhances modularity and maintainability with pure, reusable functions and predictable outputs, simplifying testing and debugging. Its immutability reduces race conditions, enabling efficient concurrency. Higher-order functions provide compact, expressive code for tasks like mapping and filtering, boosting productivity and scalability.

Thanks for your patience reading. Clap if you liked the article.

Follow me here, in GitHub and Linked-in. Stay happy and safe. Keep reading and remember one thing, “If you can solve something in some way, there is always a better way to solve it.”

“A design that doesn’t take change into account, risks major redesign in the future.” ― Erich Gamma

The SOLID principles are a set of five design principles introduced by Robert C. Martin (popularly known as Uncle Bob) that help developers design maintainable, scalable, and robust object-oriented software. These principles enable the development of software systems that are easier to understand, extend, and modify without introducing bugs or causing unintended consequences.

Single Responsibility Principle (SRP)

A class should have only one reason to change; it should have only one responsibility.

It means a class should focus on doing only one thing, and it should do it well. By adhering to SRP, you minimize dependencies and make your system easier to maintain.

Usage

1. Helps in avoiding “overloaded classes” that perform unrelated tasks.
2. Improves readability and modularity.
3. Supports testability.

Code without SRP

// Violates SRP: This class is doing multiple jobs,
// i.e, handling both persistence and notification
public class Employee {
    public void saveToDatabase() {
        // Save employee details to database.
    }
    public void sendEmailNotification() {
        // Send email notification to the employee.
    }
}

Code with SRP

// Applying SRP
public class EmployeeDatabase {
    public void save(Employee employee) {
        // Save employee details to database.
    }
}

public class EmployeeNotification {
    public void sendEmail(Employee employee) {
        // Send email notification to the employee.
    }
}

Open/Closed Principle (OCP)

A class should be open for extension but closed for modification.

Changes to functionality should be achieved by adding new code, not modifying existing code. This avoids breaking existing functionality when extending features.

Usage

1. Helps in building systems loosely coupled to reduce errors due to code modification.
2. Encourages the use of abstraction and polymorphism.

Code without OCP

// Violates OCP because adding new operations 
// requires modifying the existing Shape class

public class Shape {
    public String type;
    public double radius;
    public double height;
    public double width;

    public double calculateArea() {
        if (type.equals("circle")) {
            return Math.PI * radius * radius;
        } else if (type.equals("rectangle")) {
            return height * width;
        }
        return 0;
    }
}

Code with OCP

// Applying OCP: Use abstraction and extension instead of modification.
// With this setup, adding new shapes simply involves 
// creating a new class that extends Shape

public abstract class Shape {
    public abstract double calculateArea();
}

public class Circle extends Shape {
    private double radius;

    public Circle(double radius) {
        this.radius = radius;
    }

    @Override
    public double calculateArea() {
        return Math.PI * radius * radius;
    }
}

public class Rectangle extends Shape {
    private double height;
    private double width;

    public Rectangle(double height, double width) {
        this.height = height;
        this.width = width;
    }

    @Override
    public double calculateArea() {
        return height * width;
    }
}

Liskov Substitution Principle (LSP)

It ensures that a subclass does not modify the behavior of its superclass in a way that surprises or breaks client code.

Usage

1. Avoids unpredictable behavior in inheritance hierarchies.
2. Ensures proper polymorphism.

Code without LSP

// Example violating LSP: Rectangle and Square

public class Rectangle {
    protected int height;
    protected int width;

    public void setHeight(int height) {
        this.height = height;
    }

    public void setWidth(int width) {
        this.width = width;
    }

    public int getArea() {
        return height * width;
    }
}

public class Square extends Rectangle {
    @Override
    public void setHeight(int height) {
        super.height = height;
        super.width = height; // Force width = height
    }

    @Override
    public void setWidth(int width) {
        super.height = width; // Force height = width
        super.width = width;
    }
}

Code with LSP

// Fix: Follow LSP by avoiding forced assumptions

public interface Shape {
    int getArea();
}

public class Rectangle implements Shape {
    private int height;
    private int width;

    public Rectangle(int height, int width) {
        this.height = height;
        this.width = width;
    }

    @Override
    public int getArea() {
        return height * width;
    }
}

public class Square implements Shape {
    private int side;

    public Square(int side) {
        this.side = side;
    }

    @Override
    public int getArea() {
        return side * side;
    }
}

Interface Segregation Principle (ISP)

A client should not be forced to depend on interfaces it does not use.

It suggests splitting large interfaces into smaller, more specific ones, so that clients only depend on the methods they actually require.

Usage

1. Encourages creating smaller, cohesive interfaces.
2. Avoids unnecessary dependencies.

Code without ISP

// Violates ISP: Large interface forces unnecessary methods on classes

public interface Worker {
    void work();
    void eat();
}

public class RobotWorker implements Worker {
    @Override
    public void work() {
        System.out.println("Robot is working.");
    }

    @Override
    public void eat() {
        // Violates ISP - Robots don't eat!
        throw new UnsupportedOperationException("Robot doesn't eat.");
    }
}

Code with ISP

// Fix: Split larger interface into more specific ones
public interface Workable {
    void work();
}

public interface Eatable {
    void eat();
}

public class RobotWorker implements Workable {
    @Override
    public void work() {
        System.out.println("Robot is working.");
    }
}

public class HumanWorker implements Workable, Eatable {
    @Override
    public void work() {
        System.out.println("Human is working.");
    }

    @Override
    public void eat() {
        System.out.println("Human is eating.");
    }
}

Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Abstractions should not depend on details; details should depend on abstractions.

It encourages the use of interfaces or abstract classes to decouple high-level and low-level components in a system.

Usage

1. Reduces direct coupling between classes.
2. Promotes flexibility through the use of dependency injection.

Code without DIP

// Violates DIP: Low-level classes are directly instantiated
public class Keyboard {
    // Keyboard implementation
}

public class Computer {
    private Keyboard keyboard;

    public Computer() {
        keyboard = new Keyboard(); // Hard dependency
    }
}

Code with DIP

// Fix: Use Dependency Injection and Abstraction
public interface InputDevice {
    void input();
}

public class Keyboard implements InputDevice {
    @Override
    public void input() {
        System.out.println("Keyboard input...");
    }
}

public class Computer {
    private InputDevice inputDevice;

    public Computer(InputDevice inputDevice) {
        this.inputDevice = inputDevice; // Dependency injected
    }
}

Benefits of SOLID Principles

1. Maintainability: Code changes and extensions are less risky.
2. Scalability: New functionalities can be added easily.
3. Testability: Smaller, focused classes are easier to test.
4. Reusability: Promotes reusable components.
5. Flexibility: Reduces rigid dependencies between components.

Epilogue

The SOLID principles are essential for writing clean, efficient, and maintainable code in object-oriented programming languages like Java. While these principles are guidelines and not hard rules, following them helps achieve a robust design that adheres to industry best practices. Using SOLID principles, combined with techniques like Dependency Injection, abstraction, and modularity, leads to scalable and developer-friendly systems.