15-Day Strategy & Interview Framework

Follow a fixed order: clarify requirements, estimate scale, define APIs, sketch the data model, draw a high-level architecture, deep dive into the hardest parts, then discuss trade-offs and failures.

1. Requirements (5 min): functional, non-functional, out of scope.
2. Estimates (3-5 min): QPS, storage, bandwidth.
3. API and data model (5-7 min).
4. High-level diagram (10 min).
5. Deep dives (15-20 min) on 2 components the interviewer or the problem makes critical.
6. Bottlenecks, failure modes, monitoring, extensions (5 min).

Ask 5-8 targeted questions that change the design, state your assumptions aloud, and write them on the board.

• Functional: the 3-4 core use cases; what is explicitly out of scope.
• Non-functional: scale (DAU), latency target, availability vs consistency, durability, read/write ratio, global or single region.
• Constraints: existing tech stack, budget, team size.
• Say "I will assume X; tell me if wrong" rather than waiting for answers to every question.

Work from DAU to requests per second to storage and bandwidth using round numbers; the goal is order of magnitude, not precision.

• 1 day = ~100K seconds (86,400). 1M requests/day = ~12 QPS. Peak = 2-10x average.
• Storage = items/day x size x retention x replication (x3).
• Bandwidth = QPS x payload size.
• Memorise: 1 KB = 10^3, 1 MB = 10^6, 1 GB = 10^9; read from memory ~100 ns, SSD ~100 us, network round trip in a data centre ~0.5 ms, cross-region ~100 ms.
• Use the numbers to decide: does it fit on one machine, need sharding, or a cache?

Draw a simple end-to-end design first (breadth) so that every requirement is covered, then go deep where the problem is hardest or the interviewer shows interest.

• Start from the core flow: client, load balancer, service, database, then add cache, queue, CDN only when a requirement or estimate justifies it.
• Name the hardest part of the problem: fan-out (feed), concurrency (booking), ordering (chat), ID generation, geospatial search.
• Check in: "I would like to deep dive on X, or would you prefer Y?"

For each major decision name the options, state the criteria, choose one with a reason tied to requirements, and say what you give up and when you would revisit it.

• Pattern: "Option A gives X but costs Y; Option B ... Given our read-heavy workload and relaxed consistency, I choose A; if we need strong consistency I would switch to B."
• Quantify when possible ("adds ~1 ms", "doubles storage").
• Avoid "it depends" without finishing the sentence.
• Typical axes: consistency vs availability, latency vs cost, simplicity vs flexibility, push vs pull, SQL vs NoSQL.

The big ones are jumping into the design without requirements, name-dropping technologies without reasons, ignoring scale numbers, and never discussing failure.

• Silence: not thinking aloud, so the interviewer cannot help or give credit.
• Over-engineering: microservices, Kafka and sharding for 100 QPS.
• Single points of failure left unaddressed.
• Ignoring the data model or API entirely.
• Defending a decision rigidly against valid feedback.
• Running out of time before deep dives; poor time-boxing.

Time-box each phase and check the clock at phase boundaries; keep at least 15 minutes for deep dives.

• 0-5 requirements; 5-10 estimates and API; 10-20 high-level design; 20-40 deep dives; 40-50 failures, scaling, trade-offs; last minutes summary.
• Park tangents: "I will note that and come back to it."
• If behind, say so and compress: "In the interest of time I will outline the schema and focus on the feed generation."

Choose by access pattern and consistency need, not fashion: relational for transactions and joins, key-value/wide-column for massive scale with simple access patterns, document for flexible schemas.

• SQL: payments, orders, inventory, anything needing ACID and ad-hoc queries; scales with replicas, then sharding.
• Wide-column (Cassandra): write-heavy time-series, messages, partition by key, tunable consistency.
• Key-value (DynamoDB/Redis): sessions, caches, counters.
• Search (Elasticsearch): full-text; not a primary store.
• Say the access pattern first: "We read messages by conversation ordered by time, so partition key = conversation id."

Scale in the cheapest order that meets the numbers: optimise queries and add indexes, cache, add read replicas, scale stateless services horizontally, then shard and use queues for async work.

• Stateless services behind a load balancer scale by adding nodes; keep state in stores.
• Caching: CDN for static, Redis for hot data; state invalidation strategy (TTL, write-through).
• Replication: read scaling and availability; discuss replication lag.
• Sharding: pick a key that spreads load and matches queries; discuss hot shards, rebalancing, cross-shard queries.
• Async: queues absorb spikes and decouple services.

During a network partition you must choose between consistency and availability; otherwise (PACELC) you trade latency against consistency. Pick per feature, not per system.

• Strong consistency for money, inventory, seat booking.
• Eventual consistency for feeds, likes, view counts, search indexes.
• Tools: quorum reads/writes (R+W>N), leader-based replication, idempotency, conflict resolution (LWW, CRDTs).
• State it concretely: "The like counter can lag a few seconds; the payment ledger cannot."

Walk the diagram and ask "what if this dies, slows down, or returns garbage?" for each component, then state the mitigation: redundancy, timeouts, retries with backoff, circuit breakers, fallbacks, graceful degradation.

• Remove single points of failure: multi-AZ, replicas, leader election.
• Retries need idempotency and jitter to avoid retry storms.
• Load shedding and rate limiting protect overloaded services.
• Data: backups, point-in-time recovery, replication across regions, RPO/RTO.
• Observability: metrics (RED/USE), logs, traces, alerts on SLOs.

HLD is about components, data flow, scale and trade-offs; LLD is about classes, interfaces, patterns, correctness and concurrency inside one service.

• HLD artifacts: diagram, API, schema, estimates; LLD artifacts: class diagram and compilable code.
• LLD scoring: clean abstractions, SOLID, extensibility, thread safety, edge cases, tests.
• Prepare differently: HLD by studying building blocks and canonical systems; LLD by coding 10-15 problems yourself.

Load balancers, CDNs, caches, SQL and NoSQL databases, replication and sharding, message queues/streams, object storage, search indexes, consistent hashing, and rate limiting.

• Know when each is appropriate and its failure behaviour (e.g., Kafka partition ordering, Redis persistence modes, S3 consistency).
• Patterns: cache-aside, CQRS, outbox, saga, leader election, idempotency keys, bloom filters, geohashing.
• Protocols: HTTP/REST, gRPC, WebSocket, long polling, SSE.

Spend days 1-4 on fundamentals, days 5-6 on LLD fundamentals and practice, days 7-12 on canonical HLD systems, days 13-14 on mocks, and day 15 on review and rest.

• Day 1: framework, estimation, latency numbers. Day 2: databases, indexing, replication, sharding.
• Day 3: caching, CDN, load balancing, consistency models (CAP). Day 4: queues, streams, async patterns, idempotency.
• Day 5: SOLID and design patterns; code 2 LLD problems. Day 6: concurrency in LLD; code 3 more.
• Day 7: URL shortener, pastebin, rate limiter. Day 8: news feed, notifications. Day 9: chat, presence.
• Day 10: file storage, video streaming. Day 11: ride sharing, search autocomplete, crawler.
• Day 12: payments, checkout, ticket booking. Day 13: two timed mocks. Day 14: weak areas, one mock. Day 15: skim notes, rest.

Practise out loud with a timer and a whiteboard, then compare with a reference and write down gaps; active practice beats passive reading.

• Per problem: 40 minutes solo design, 15 minutes review, one-paragraph summary of key decisions.
• Keep a one-page cheat sheet: estimation numbers, building block pros/cons, patterns.
• Read real engineering blogs (Uber, Netflix, Discord, Stripe) to see actual trade-offs.
• Do at least 3 mocks with a partner and ask for blunt feedback.
• For LLD, type compilable code in an editor, not pseudocode.

Treat push-back as collaboration: acknowledge, restate the concern, evaluate it against requirements, and adapt or defend with evidence.

• "Good point, that breaks at 10x write volume. Then I would partition by user id and move that path to async."
• A hint usually signals a missed requirement or a better direction; take it without defensiveness.
• If you disagree, explain the trade-off politely and ask what constraint they have in mind.

Left to right flow from clients to storage, labelled boxes, arrows with direction and protocol/sync-async, a legend for queues and caches, built incrementally.

• Start with the minimal path, then add components as justified.
• Label data stores with what they hold and the partition key.
• Mark synchronous (solid) vs asynchronous (dashed) paths.
• Number the steps of the main flow and narrate them.
• Keep it readable; avoid drawing every replica.

Seniors drive the conversation, tie every decision to requirements and cost, anticipate failure and operations, and discuss evolution over time.

• Proactively define SLOs, rollout, migration and monitoring.
• Mention operational concerns: on-call load, deployment safety, cost per request, data privacy and compliance.
• Discuss phased delivery: what is built in v1 versus later.
• Reference real experience: "In a similar system we saw hot partitions, so we..."
• Identify the riskiest assumption and how to de-risk it.

After each mock, score yourself on a fixed checklist and record one improvement for the next.

• Clarified functional and non-functional requirements and stated assumptions.
• Did estimates and used them to drive a decision.
• Defined APIs and a data model with keys and indexes.
• Drew a clear diagram that covers every requirement.
• Deep dived on the hardest 1-2 problems with alternatives.
• Discussed trade-offs, bottlenecks, and at least three failure modes.
• Mentioned monitoring, security and data consistency.
• Managed time and communicated continuously.
• Responded well to hints.

Warm up lightly with one familiar problem or your cheat sheet, prepare your whiteboard/tool setup, and keep a calm, structured mindset; do not learn new topics.

• Test your video, audio, and the shared drawing tool; have paper for notes.
• Re-read the framework steps and latency numbers.
• During the session: think aloud, ask clarifying questions, keep an eye on time, and summarise at the end.
• If you blank, restate requirements and draw the simplest possible design; momentum returns.