🗺️ Roadmap

The map I used to prepare for backend / SDE-2 interviews. Everything on this site hangs off these buckets.

Mandatory for SDE-2 backend interviews

Requirement gathering → YAGNI. Plan execution → KISS. Keep a record of progress → SOLID.

HLD Fundamentals

The 19 building blocks every high-level design conversation is made of. Know the what, the when, and one trade-off for each.

1. Capacity estimation — tables, powers of 2 and 10, million/billion/trillion, KB→MB→GB relations.
2. HTTP & HTTPS — REST, methods (GET/PUT/POST/PATCH/DELETE), status codes, TLS.
3. Server → client push — WebSockets (chat, stock ticks), Polling, Server-Sent Events.
4. Horizontal vs vertical scaling — difference, when to use what.
5. Latency & throughput — p50/p99, QPS.
6. CAP theorem — under partition pick C or A; fintech ⇒ consistency > availability.
7. Load balancers — see Load Balancers & Proxies.
8. Proxies — forward vs reverse, and why.
9. Consistent hashing — distribute traffic/data across servers so adding/removing a node moves minimal keys.
10. SQL vs NoSQL — ACID; key-value, document, graph; when to use what; how each scales.
11. Storage — BLOB/object storage (images), Quad Trees (maps/location), graph stores.
12. Indexing — speeds reads, slows writes. Decide per access pattern.
13. Replication & sharding — data can't live in one place (failure + latency). Replicate to survive; shard to partition.
14. Caching — hit/miss, eviction (LRU, LFU, FIFO), and why one policy suits your system.
15. Message queues & Pub/Sub — async processing, decoupling sender & receiver, absorbing spikes.
16. Resiliency — retries, timeouts, circuit breakers, fallbacks, graceful degradation.
17. Paging & filtering — offset/limit or cursor; bring it up yourself for any large dataset.
18. Rate limiting — per user/IP/time window; protects cost, prevents bot abuse.
19. Logging & monitoring — what happened, where, and alerts on it.

How to drive the conversation

• Clarify functional + non-functional requirements first (scale, latency, consistency).
• Estimate: DAU → requests/day → QPS → storage/bandwidth.
• Draw the high-level boxes, then go deep on two components (usually DB schema + caching).
• Always say why you chose a trade-off, not just what you picked.

Back-of-envelope Estimation

Memorise a handful of numbers and follow a fixed template — that gets you 80% of the way.

Numbers to memorise

The template

1. DAU — given or estimated.
2. Requests per user per day → multiply → total requests/day.
3. ÷ 100K → average QPS. Peak ≈ 2–3× average.
4. Storage = writes/day × object size × retention (years).
5. Bandwidth = QPS × response size.
6. Cache — 80/20 rule: cache 20% of daily read volume.

Example — URL shortener
100M DAU × 1 write/day            = 100M writes/day  → ~1K write QPS
reads 10× writes                  = 1B reads/day     → ~10K read QPS
each record ≈ 500 B × 100M × 365 × 5y ≈ 90 TB over 5 years

Distributed Systems Concepts

Vocabulary that comes up in every HLD discussion — with the precise meaning, not the hand-wavy one.

Idempotency

An operation is idempotent if executing it multiple times with the same input produces the same result as executing it once. PUT is idempotent; PATCH and POST generally are not. Pair idempotent APIs with retry + exponential backoff. Store idempotency keys durably — Redis can go down, so keep a DB fallback.

Consistency

• Eventual consistency — "quick response now, consistent eventually". Fine when real-time accuracy isn't critical (DynamoDB, WhatsApp profile picture propagating across devices).
• Dirty read — reading data another transaction modified but hasn't committed.
• Skewed / stale read — write to node A, read from node B before replication catches up. A side effect of eventual consistency.
• Materialized view — a DB object storing precomputed query results.

Race conditions

A timing bug between concurrent operations: multiple threads/processes touch shared data, at least one writes, and there's no synchronisation. Classic: two users buy the last item at once → overselling.

• Locks / mutexes around shared resources
• Atomic operations (AtomicInteger, DB atomic updates)
• Thread-safe data structures · DB transactions (ACID) · synchronized

Failover · Fallback · Failback

Safe failback needs: health checks, data sync, LB switching, automation, quorum checks, graceful shutdown, shadow testing, and (for critical systems) manual approval.

Coupling

Pub/Sub has loose coupling, not no coupling — publishers and subscribers still agree on topic name, message schema, semantics, and broker.

Other terms worth owning

• Transition state — a short-lived intermediate state ("Authenticating", "Processing Payment") between stable states.
• Dedupe — keep one unique copy, link the rest. Saves storage, cleans lists, stops fraud.
• Sidecar — helper process/container attached to the main app for auxiliary tasks (proxying, logging, auth).
• Upstream / downstream — services you call vs services that call you.
• Fan-out / fan-in — one event to many consumers / many results merged into one.
• Complacency trap — assuming you know everything so you stop asking questions. Dangerous in design reviews.

Kafka

Distributed messaging / event-streaming platform. Logs, sensor data, events — stock market feeds, social feeds, IoT. High throughput and horizontally scalable.

Core vocabulary

• Producer / Consumer
• Topic — logical category/feed, like a DB table.
• Broker — a server; a cluster is multiple brokers.
• Partition — unit of parallelism. Ordering is guaranteed only within a partition.
• Offset — sequential id of a message inside a partition.
• Replication factor — avoid single point of failure.
• Consumer group — each partition consumed by exactly one consumer in the group (load balancing + fault tolerance). Each group keeps its own offsets, so multiple apps can consume the same stream independently (broadcast).

Why is Kafka fast if it writes to disk?

• Sequential, append-only writes — linear disk writes can beat random memory access.
• Zero-copy transfer — bypasses the user-space copy between disk and socket.
• OS page cache instead of an in-process cache — no JVM GC penalty, cache stays warm across restarts.
• Producer parallelism — keyed messages hash to a partition; unkeyed are round-robined.

Producer acks

Operational things interviewers probe

• Rebalance is "stop-the-world" — consumption pauses while partitions are reassigned. Use static membership in volatile environments (K8s spot instances) to avoid full rebalances.
• Consumer lag — delay between produce and successful consume; the key health metric.
• Restart semantics — a consumer resumes from its group's last committed offset; a dead pod's partitions are reassigned to surviving members of the group.
• Pair Kafka with the Outbox pattern for exactly-once-ish DB + event publishing.

Redis & Caching

Redis is more than a cache: cache, Pub/Sub, persistence (snapshot or append-only file), locks (Redisson), rate limiting.

Caching basics

• Hit / miss, TTLs, cache-aside vs write-through vs write-behind.
• Eviction: LRU, LFU, FIFO — be ready to argue why one suits your system.
• Cache ~20% of hot data (80/20 rule) for most read-heavy systems.
• Caching a balance or anything money-related? Treat the DB as source of truth; cache only derived/read views.

Redis vs Memcached

Memcached is a pure in-memory key-value cache. Redis adds data structures (lists, sets, sorted sets, hashes), persistence, Pub/Sub, Lua scripting and clustering.

Redis Cluster — slot-to-node metadata cache

Keys hash (CRC16) into 16,384 slots spread over nodes. The client caches the slot→node topology so each command is one network trip instead of "ask where key lives, then send command".

Without metadata cache:  App → ask cluster where key lives → answer → send command   (2 trips)
With metadata cache:     App → local topology → send command directly             (1 trip)

Why not implement that map in your own service? You'd also need slot calculation, cluster discovery (CLUSTER SLOTS), MOVED handling, rebalancing, retries, failover, connection management and health checks. That's why Jedis / Lettuce / Redisson exist.

Idempotency store

Redis can go down. If you store idempotency records only in Redis you can double-process. Keep a durable record in the database and use Redis as the fast path.

CDN

Geographically distributed cache for static (and increasingly dynamic) content — video chunks (~4 s MP4 segments with a manifest listing bitrates for ABR/HLS/DASH), images, JS/CSS.

Load Balancers & Proxies

A proxy is an intermediary acting on behalf of another entity. A load balancer is a reverse proxy that distributes load across instances of the same service.

Forward vs reverse proxy

Load-balancing algorithms

1. Round Robin
2. Weighted Round Robin
3. Least Connections
4. Geographical
5. IP Hashing — sticky sessions; stateful requests become easy
6. Network bandwidth–aware (e.g. video streaming)

Good LBs also watch %CPU, RAM and in-flight requests via health checks / heartbeats to make better decisions. Keep health-check polling short.

Consistent hashing

Place servers and keys on a hash ring; a key goes to the next server clockwise. Adding/removing a server moves only the keys in one arc, not everything. Use virtual nodes to spread load evenly. Questions to be able to answer: how data migrates when a shard is added/removed, who manages it (app layer vs DB layer), and how the app connects to shards + replicas (e.g. MongoDB mongos router, PostgreSQL read replicas).

Databases & Storage

What to know, grouped the way interviewers ask about it.

Indexing — the rule

Indexes make reads faster and writes slower. Decide based on the system's access pattern, and say so out loud in an interview.

Replication & sharding

• Data can't live in one place: a single location fails, and you want data near the client.
• Replicate to survive failures and serve reads. Shard (partition) to scale writes and storage.
• Pick the shard key by the dominant query pattern; avoid hot shards.

Communication & APIs checklist

JWT · OAuth · CORS · throttling · serialization (Protocol Buffers) · REST vs gRPC · API versioning · API gateway · service mesh · long polling · WebSockets · idempotency · retry patterns · circuit breaker · message queues · dead-letter queue.

Reliability & observability checklist

Metrics · logging · distributed tracing · alerting · SLO/SLI/SLA · error budgets · health checks · heartbeats · autoscaling · load testing · canary / blue-green deployments · rollbacks · graceful degradation · chaos engineering · incident response.

Must-solve Design Problems

Grouped by the dominant pressure in the system. For each, the bullets are what the interviewer actually wants you to focus on.

Read-heavy

• URL shortener — key generation, collisions, DB/caching, sharding
• Image hosting — object storage, CDN, deduplication, resizing
• Social platform — posts, timelines, denormalised storage, sharding
• News feed — push vs pull, fan-out, ranking, pagination

Write-heavy

• Rate limiter — token/leaky bucket, Redis, TTL
• Log collection & analysis — Kafka, ELK, partitioning, real-time query
• Voting system — idempotency, fraud prevention, real-time aggregation
• Trending topics — count-min sketch, sliding window, ranking

Search, messaging & delivery

• Word dictionary — trie, prefix lookups
• Text search engine — tokenisation, inverted index, ranking
• SQL-backed message broker — durability, ordering, delivery semantics
• Distributed task scheduler — idempotency, retries, time-based triggering
• Recent searches — LRU cache, user isolation

Fintech flavour (SDE-2 product companies)

Order placement, portfolio feed, notification system, payment processing, real-time price feed. Remember: consistency > availability, and go deep on two components — usually schema + caching.

How to approach an LLD problem

Use this as your script. Timings are for a 45–60 min round. Always narrate why you choose an approach.

1. Clarify requirements & scope (1–2 min) — core operations, scale, performance goals, persistence, correctness vs eventual, concurrency needs. Decide constraints: single node vs distributed, QPS, memory.
2. State APIs / use-cases (1–3 min) — list main APIs with example calls and input/output shapes.
3. High-level components (2–5 min) — draw boxes for main classes/components and their interactions. Simple first.
4. Detailed class design (5–12 min) — classes, methods, key fields, relationships (aggregation/inheritance). Highlight interfaces/abstractions (SOLID). Show the sequence for main flows.
5. Data structures & algorithms (3–8 min) — pick DS for critical ops (priority queue, hashmap, LRU list) and state complexity.
6. Concurrency & correctness (2–6 min) — race conditions, locks vs lock-free, thread-safety (synchronized, atomics, concurrent collections), transactional boundaries.
7. Persistence (2–5 min) — RDBMS vs NoSQL, schema sketch, indices, caching layers.
8. Scaling & availability (2–6 min) — bottlenecks → partitioning, replication, caching, queueing, graceful degradation.
9. Edge cases & failure modes (2–5 min) — input errors, retries, duplicates, partial failures, network partitions.
10. Testing & metrics (1–3 min) — unit/integration tests, key metrics and alerts.
11. Extensions & trade-offs (1–3 min) — what you'd add next and what you consciously gave up.

Practice set

Hotel Management · Car Parking · Elevator · Chess · Ticket Booking · ATM · Tic-Tac-Toe. Resources: codezym.com, "System Design and Gossip" on YouTube.

Moving from definitions to instinct

Practise scenario-based quizzes, "class vs interface vs abstract class?" questions, pattern identification, and refactoring exercises. Group similar patterns (Factory/Abstract Factory, Decorator/Proxy, Strategy/State) and for each ask: what's the problem, which pattern solves it, how does it look in real code?

SOLID Principles

Core intention: control change. SOLID is not about splitting everything — it's about finding volatility points (where change happens) and applying principles there.

S — Single Responsibility

"A class should have only one reason to change." Think Swiss Army knife: sharpen the blade and you carry the whole tool. Granularity: class level (sometimes method).

// ❌ three reasons to change: business rule, email provider, DB
class UserService {
  void registerUser(User u) {}
  void sendEmail(User u) {}
  void saveToDB(User u) {}
}

// ✅ SRP applied
class UserService   { void registerUser(User u) {} }
class EmailService  { void sendEmail(User u) {} }
class UserRepository{ void save(User u) {} }

If a class has multiple reasons to change, split it.

O — Open/Closed

"Open for extension, closed for modification." A game doesn't change when a new controller ships — the controller implements the standard interface. Apply where behaviour varies (payments, notifications, storage types).

// ❌ every new payment type modifies this
if (type.equals("CARD")) ... else if (type.equals("UPI")) ...

// ✅
interface Payment { void pay(); }
class CardPayment implements Payment {}
class UpiPayment  implements Payment {}

L — Liskov Substitution

"Subtypes must be substitutable for their base types." A Smart TV remote must still have a working power button. Square/Rectangle with setWidth/setHeight is the classic violation. Applies only where inheritance exists.

// ❌
class Bird { void fly() {} }
class Ostrich extends Bird { void fly() { throw new UnsupportedOperationException(); } }

// ✅ fix the abstraction
interface Bird {}
interface FlyingBird extends Bird { void fly(); }
class Sparrow implements FlyingBird {}
class Ostrich implements Bird {}

If a child cannot honour parent behaviour → wrong abstraction.

I — Interface Segregation

"Clients shouldn't depend on interfaces they don't use." Separate breakfast / lunch / drinks menus instead of one giant page.

// ❌ Tester forced to implement code()
interface Worker { void code(); void test(); void deploy(); }

// ✅
interface Coder  { void code(); }
interface Tester { void test(); }
interface DevOps { void deploy(); }

D — Dependency Inversion

"High-level modules should not depend on low-level modules; both depend on abstractions." The lamp has a plug, the wall has a socket — neither cares about the other's wiring. Bonus: interfaces are mockable, concrete classes aren't. Apply at system boundaries: DB, APIs, messaging, storage.

// ❌
class OrderService { MySQLDB db = new MySQLDB(); }

// ✅ inject the abstraction
class OrderService {
  private final DBInterface db;
  OrderService(DBInterface db) { this.db = db; }
}

Where each applies

Design Patterns Cheat Sheet

When to use · what to use · how it works. Revise by grouping similar patterns and coding two a day.

Creational

Structural

Behavioural

How to revise

• Group similar patterns: Factory & Abstract Factory · Decorator & Proxy · Strategy & State.
• For each ask: what is the problem? which pattern solves it? how does it apply in real code?
• Code 2 patterns a day, even with print statements.
• Real-world anchors help: Google Maps ≈ Flyweight + Proxy.

OOP Relationships

Association vs Aggregation vs Composition — and the four questions that settle it every time.

The decision ladder

1. Do the objects relate at all? If they know about / use each other → at least an Association. (Teacher teaches Student.)
2. Is one a whole and the other a part? No → stay with Association. Yes → go deeper.
3. Who owns the lifecycle? Part dies with the whole → Composition (Human → Heart). Part lives independently → Aggregation (Library → Books).
4. Association vs Aggregation — both allow independent lifecycles. Ask: is one logically "part of" the other? Yes → Aggregation (Classroom–Students). No, just a link → Association (Teacher–Student).

Mental shortcut

If "X has Y" sounds natural → whole–part (Aggregation / Composition). If only "X works with Y" sounds natural → Association.

Related vocabulary

• Upcasting — superclass reference pointing at a subclass object.
• Loose coupling — code written against an interface; swap the implementation without touching callers.
• High cohesion — interfaces define clear, focused responsibilities.

Machine Coding Round

90–120 minutes, working code, clean structure. Here's the order of operations and the shortcuts that save time.

Order of operations

1. List all entities → see how they link → implement only the basic requirement set first.
2. Keep code clean while creating objects → Factory for entity creation, Builder when there are many optional fields.
3. Keep SOLID intact → corresponding interfaces, Dependency Inversion, Strategy for pluggable behaviour.

Don't overthink IDs

No database, no UUID complexity. A static counter inside the class is enough.

public class User {
  private static int counter = 0;      // class-level counter
  private final String id;
  private final String name;

  public User(String name) {
    this.id = "USR-" + (++counter);    // USR-1, USR-2, USR-3
    this.name = name;
  }
}

Checklist before you say "done"

• Main flow demonstrable from a main() or test.
• Interfaces for anything that could vary (pricing, notification, storage).
• Thread-safety called out where shared state exists (even if not implemented).
• Edge cases listed verbally: invalid input, duplicates, empty states.

C++ STL — things to care of

The traps that bite in interviews and production, plus the STL → Java mapping for when you switch languages.

Things to care of

• priority_queue is a max-heap by default. Min-heap: priority_queue<int, vector<int>, greater<int>>. (Java's PriorityQueue is the opposite — min-heap by default.)
• Iterator invalidation. vector::push_back may reallocate and invalidate all iterators/pointers/references; erase invalidates from the erased point onward. unordered_map rehash invalidates iterators (not references). map/set/list only invalidate the erased element.
• Comparators must be a strict weak ordering. Return true only when a is strictly before b. Using <= is undefined behaviour in sort and can crash.
• operator[] on a map inserts. m[k] default-constructs a value if missing. Use find / count / at for read-only lookups.
• unordered_map worst case is O(n). Adversarial inputs can trigger collisions — in contests use a custom hash or fall back to map.
• lower_bound / upper_bound need sorted ranges. On set/map use the member versions (O(log n)), not std::lower_bound (O(n) on non-random-access iterators).
• reserve() when you know the size — avoids repeated reallocation. emplace_back constructs in place; push_back copies/moves.
• Erase-remove idiom: v.erase(remove_if(v.begin(), v.end(), pred), v.end()); — or std::erase_if(v, pred) in C++20.
• size() is unsigned. v.size() - 1 on an empty vector wraps around. Compare with int carefully.
• Prefer std::array / vector over raw arrays; prefer string_view for read-only string params.
• Pass large containers by const&; return by value (RVO / move semantics make it cheap).
• std::deque is the right default for queues/stacks (stack and queue are adaptors over it).

Complexity reminders

C++ STL → Java mapping

Java Essentials

The idioms and gotchas that matter most when you're writing Java under interview pressure.

Golden rule: declare with the interface type

List<String> names = new ArrayList<>();     // ✅
Map<String, Integer> freq = new HashMap<>();
Set<String> seen = new HashSet<>();

ArrayList<String> names = new ArrayList<>(); // ❌ too specific

Swap ArrayList for LinkedList later by changing one word, not every signature.

HashMap — the patterns you'll use most

map.get("a");                       // returns null if absent — NOT an exception
map.getOrDefault("a", 0);           // safe get
map.merge("a", 1, Integer::sum);    // frequency count
map.computeIfAbsent("a", k -> new ArrayList<>()).add("item");  // multimap
for (Map.Entry<String,Integer> e : map.entrySet()) { e.getKey(); e.getValue(); }

map.get() returns null for missing keys. Always use getOrDefault() unless you're explicitly checking for null.

No built-in Pair → use a record

record Point(int x, int y) {}
public record Pair<L, R>(L left, R right) {}

Point p = new Point(3, 5);  p.x();  p.y();          // accessors, no 'get'
Map<Point, String> grid = new HashMap<>();         // equals/hashCode auto-generated

Records are immutable, so they're safe as map keys and in sets.

Sorting

Collections.sort(nums);                        // ascending
nums.sort(Comparator.reverseOrder());          // descending
Arrays.sort(arr);                              // int[] ascending (no reverse for primitives)
cars.sort(Comparator.comparingInt(Car::price).thenComparing(Car::name));
cars.sort((a, b) -> b.speed - a.speed);        // lambda, descending by speed

Primitive vs reference fields

• Primitive (int, boolean…) stores the value directly, fixed size, never null, no methods.
• Reference (any class, interface, enum, array, String) stores an address into the heap; can be null; has methods.
• Assigning a primitive copies the value; assigning a reference copies the address — both now point to the same object.

Java is strictly pass-by-value

What's passed by value for a reference type is the reference. So a method can mutate the object you passed, but reassigning the parameter inside the method doesn't affect the caller.

static void modify(List<String> list) {
  list.add("Orange");          // ✅ visible to caller — same object
  list = new ArrayList<>();    // ❌ only rebinds the local copy of the reference
  list.add("New Item");
}

Also know

java.util.function (Function, Supplier, Consumer, Predicate) · Stream API (map/filter/collect/groupingBy) · java.lang.Object contract (equals/hashCode/toString) · Generics (bounded types, wildcards) · JVM memory & GC · JAVA_TOOL_OPTIONS (JVM-level) vs application.properties (Spring-level).

Java Concurrency & Spring

The one mental model: a thread is needed to execute CPU work, but it does not need to stay occupied while waiting for non-blocking I/O.

Blocking vs non-blocking I/O

Blocking:      Thread → send request → WAIT ……………… response → continue
               (thread occupied the whole time)

Non-blocking:  Event loop → start A → start B → process C → start D
               → later: A's response arrives → process A
               (no thread sits waiting on A)

Spring Boot (MVC) uses a multi-threaded thread pool — one thread per in-flight request. Spring WebFlux on Netty uses an event loop; the controller returns Mono/Flux and Spring subscribes as part of handling the request.

Singleton beans and thread safety

Spring creates one instance of a @Service and reuses it. Threads 1…N all call the same object.

@Service
public class PaymentService {
  public Payment getPayment(String id) {   // local variables only → stateless → thread-safe
    return fetchPayment(id);
  }
}

Stateless is one way to be thread-safe. But thread-safe ≠ stateless — you can hold state if it's protected (concurrent collections, atomics, locks).

Toolbox

Singleton pitfalls (LLD favourite)

• Lazy initialisation needs double-checked locking with a volatile field — or just use an enum / static holder.
• Reflection and serialization can create a second instance; guard the constructor and implement readResolve().

Database locking recap

Databases use shared locks for reads and exclusive locks for writes. Many shared locks coexist; an exclusive lock blocks both. Deadlocks are detected with wait-for graphs — on a cycle, one transaction is chosen as victim and rolled back.