Use a consistent framework to avoid jumping into architecture too early.

Step 1 — Clarify requirements (5–10 minutes)

• Functional: What must users be able to do?
• Non-functional: What latency, availability, consistency, durability, security, and scale are required?
• Scope: What is explicitly out of scope?
• Actors: Who uses the system, and what permissions do they have?

Step 2 — Estimate scale (5 minutes)

• Daily active users and peak concurrent users.
• Requests per second, read/write ratio, and peak-to-average ratio.
• Storage growth, retention, bandwidth, and cache requirements.

Step 3 — Define APIs and data models (5–10 minutes)

• Identify primary entities and relationships.
• Define core read/write operations.
• Specify pagination, idempotency, authorization, and error behavior.

Step 4 — Draw the high-level architecture (10 minutes)

• Clients, DNS, CDN, load balancer, application services, caches, databases, queues, object storage, and external dependencies.
• Explain why each component exists.

Step 5 — Deep dive into critical paths (15–20 minutes)

• Select the hardest or most important flows.
• Trace requests through the system.
• Discuss bottlenecks, consistency, concurrency, retries, and failure handling.

Step 6 — Cover reliability and trade-offs (5–10 minutes)

• Identify single points of failure.
• Explain replication, recovery, observability, security, and capacity limits.
• State what you would improve first as traffic grows.

Interview rule: explain the simplest design that satisfies the requirements, then evolve it when a specific constraint justifies added complexity.

Functional requirements describe what the system does: create an order, upload a file, send a message, search products, or follow a user.

Non-functional requirements describe how well it must operate.

Attribute	Interview question	Typical design implications
Latency	How quickly must a request complete?	Caching, indexing, locality, async processing
Throughput	How many operations per second?	Horizontal scaling, batching, partitioning
Availability	What fraction of time must it work?	Redundancy, failover, graceful degradation
Durability	Can acknowledged data be lost?	Replication, persistent logs, backups
Consistency	How quickly must writes become visible?	Strong reads, quorum protocols, coordination
Scalability	How does capacity grow with load?	Stateless services, partitioning, autoscaling
Security	Who may access which data?	Authentication, authorization, encryption, audit logs
Maintainability	How safely can the system evolve?	Clear boundaries, automation, testing, observability

Clarify the scope: distinguish must-have requirements from optional features. For example, a URL shortener may require creating and resolving links, while analytics, custom aliases, and expiration policies may be secondary.

Translate vague goals into measurable targets: replace 'fast' with a target such as p95 latency below 200 ms for a specified operation; replace 'highly available' with a defined availability objective. Targets depend on the product and must be agreed upon rather than assumed.

Prioritize quality attributes: some goals conflict. Strong consistency can increase latency or reduce availability during network partitions. Durability and multi-region recovery can increase cost. State which requirements dominate.

Estimates help identify orders of magnitude and likely bottlenecks. State assumptions and round numbers instead of pretending estimates are exact.

Traffic formulas

• Average requests per second = daily requests / 86,400.
• Peak RPS = average RPS × peak-to-average multiplier.
• Write RPS = total RPS × write fraction.
• Read RPS = total RPS × read fraction.
• Approximate concurrent requests = RPS × average request duration in seconds.

Storage formulas

• Raw storage = records per day × average record size × retention days.
• Replicated storage = raw storage × replication factor.
• Total storage should also account for indexes, metadata, logs, and growth overhead.
• Image/video storage = uploads per day × average object size × retention days.

Bandwidth formulas

• Average bandwidth in bytes/second = RPS × average payload size in bytes.
• Approximate bits/second = bytes/second × 8.
• Outbound bandwidth may dominate when responses contain large media objects.

Example: 10 million daily active users Assume each user generates 20 requests per day.

• Daily requests = 10,000,000 × 20 = 200,000,000.
• Average RPS = 200,000,000 / 86,400 ≈ 2,315.
• If peak traffic is 4× average, peak RPS ≈ 9,260.
• If 80% are reads, peak read RPS ≈ 7,408 and write RPS ≈ 1,852.

Example: storage growth Assume 5 million new records per day, each averaging 1 KB, retained for 365 days.

• Raw daily growth ≈ 5 GB using decimal units.
• Annual raw data ≈ 1.825 TB.
• With three copies, replicated data alone is approximately 5.475 TB, excluding indexes and overhead.

Useful relationship: Little's Law Average in-flight work = throughput × average time in the system. At 2,000 requests/second and 0.2 seconds average latency, expect approximately 400 requests in flight.

Interview checklist: specify units, distinguish average from peak, include growth and retention, estimate payload sizes, and identify which assumptions most affect the result.

Component	Primary purpose	Use when	Watch out for
CDN	Cache content near users	Static assets, media, cacheable responses	Invalidation, stale content, private-data leakage
Load balancer	Distribute incoming traffic	Multiple service instances	Health checks, connection draining, sticky sessions
API gateway	Centralize API routing and policies	Multiple APIs or services	Becoming a bottleneck or policy monolith
Application service	Execute business logic	Domain operations and workflows	Stateful instances, overloaded responsibilities
Cache	Reduce repeated reads and latency	Hot or recomputable data	Staleness, eviction, stampedes
Relational database	Transactions and relational queries	Strong constraints and multi-row transactions	Hot rows, connection limits, write scaling
Document database	Flexible document-shaped records	Aggregate-oriented access patterns	Cross-document transactions and index design
Key-value store	Fast lookup by key	Sessions, counters, simple access patterns	Limited query flexibility
Search engine	Full-text and relevance search	Text search, filtering, ranking	Eventual indexing and operational complexity
Message broker	Decouple producers and consumers	Async jobs and event-driven workflows	Duplicate delivery, backlog, ordering
Object storage	Durable blob storage	Images, videos, backups, large files	Access control, metadata lookup, lifecycle policies
Stream processor	Process continuous event flows	Real-time metrics and transformations	Late events, replay, state management

A common request path: client → DNS/CDN → load balancer or gateway → application service → cache/database or message broker → response.

Not every architecture needs every component. Add a component only when a requirement, bottleneck, isolation boundary, or failure mode justifies it.

API design checklist

• Use resource-oriented names and consistent HTTP semantics where appropriate.
• Validate input at the boundary and return stable error formats.
• Define authentication, authorization, rate limits, and request size limits.
• Use pagination for potentially large result sets.
• Use idempotency keys for retryable operations that must not create duplicate effects.
• Version APIs when changes are not backward compatible.
• Set explicit timeouts and define retry behavior for clients.

Pagination choices

• Offset pagination: easy to understand; large offsets can be expensive and results can shift during concurrent writes.
• Cursor pagination: better for large or changing datasets when backed by a stable indexed sort key; requires cursor management.

Data modeling checklist

• Start from access patterns and query requirements.
• Identify entities, relationships, uniqueness constraints, and lifecycle rules.
• Define indexes for actual query patterns and sort orders.
• Consider write amplification, index size, hot keys, and data growth.
• Decide which data is authoritative and which is derived.

Example: order creation POST /orders should validate the cart, verify pricing and inventory according to business rules, and use a durable transaction or workflow where necessary. A client retry should not accidentally create multiple orders; an idempotency key can bind retries to the original result.

Avoid: exposing internal database schemas directly as public API contracts, allowing unbounded list endpoints, and relying on client-side validation for security.

Relational databases are strong defaults when transactions, constraints, joins, and structured relationships matter. They can scale substantially with good schema design, indexes, read replicas, and partitioning.

Document databases fit aggregate-oriented records with flexible structures and access patterns that can be served without many joins. They still require schema discipline and careful index design.

Key-value databases fit direct key-based lookups, sessions, and simple high-throughput access patterns.

Wide-column databases can support large distributed workloads when access patterns and partition keys are well understood.

Graph databases are useful when traversals across relationships are central to the product.

Search indexes support full-text search and relevance ranking; they are commonly derived from authoritative data stores and may update asynchronously.

Indexing rules

• Index fields used in frequent filters, joins, and sorting.
• For compound indexes, reason about field order and the actual query predicates.
• Indexes speed up supported reads but add storage and write-maintenance cost.
• Inspect query plans rather than guessing.
• Avoid indexing every field by default.

Replication versus partitioning

• Replication keeps copies of data for redundancy and read distribution.
• Partitioning divides data across nodes to distribute storage and load.
• Sharding introduces routing, rebalancing, cross-shard queries, and operational complexity.

Decision rule: choose the simplest database that satisfies correctness and access-pattern requirements. A popular database is not automatically the right database.

Common patterns

• Cache-aside: application checks cache, loads from the database on a miss, then populates the cache.
• Read-through: cache abstraction loads missing values from the backing store.
• Write-through: writes update cache and backing store in a coordinated path.
• Write-behind: cache accepts writes and persists them asynchronously; this introduces durability and recovery risks.
• CDN caching: serves eligible responses near users.

Cache decisions

• What is the cache key?
• How long may data remain stale?
• What triggers invalidation?
• What happens on cache failure?
• Can a hot key overload one node?
• Can many simultaneous misses overload the database?

Common problems

• Cache stampede: many requests regenerate the same missing item. Use request coalescing, jittered TTLs, or controlled refresh.
• Hot key: one key receives disproportionate traffic. Consider replication, local caching, or key splitting where semantics allow.
• Stale data: use explicit freshness requirements and invalidation strategies.
• Cache penetration: repeated requests for nonexistent data can bypass the cache; carefully cache negative results when appropriate.

Cache hit ratio = cache hits / total cache lookups.

A high hit ratio is useful but does not guarantee good performance; a few expensive misses or oversized values can still dominate latency. Never treat a cache as the sole durable copy of important data unless its durability guarantees explicitly support that design.

Consistency models

• Strong consistency: reads observe writes according to the system's defined ordering guarantees.
• Eventual consistency: replicas may temporarily disagree but converge if updates stop and propagation succeeds.
• Read-your-writes: a client can observe its own completed writes.
• Monotonic reads: a client does not move backward to older observed values.
• Causal consistency: causally related operations preserve their ordering.

CAP theorem When a network partition occurs, a distributed data system cannot guarantee both linearizable consistency and availability for every request in the formal CAP sense. It must define which operations are rejected, delayed, or served with weaker guarantees during a partition. CAP is not a general rule that a system simply chooses any two qualities at all times.

Replication concepts

• Leader-based replication routes writes through a leader or leader group.
• Multi-leader designs allow writes in multiple locations but need conflict handling.
• Leaderless designs may use quorums and reconciliation.
• Quorum arithmetic alone does not guarantee linearizability; the protocol and failure model matter.

Idempotency An operation is idempotent if repeating it has the same intended effect as executing it once. Use idempotency keys, deduplication records, unique constraints, or naturally idempotent state transitions to control duplicate effects.

Delivery semantics

• At-most-once: messages may be lost, but are not redelivered under the defined semantics.
• At-least-once: messages may be redelivered, so consumers must tolerate duplicates.
• Exactly-once claims are usually scoped to a specific system boundary. External side effects often still require idempotency or transactional coordination.

Clocks and ordering Wall clocks can drift and do not reliably establish causal order across machines. Use sequence numbers, versions, logical clocks, or protocol-specific ordering when correctness depends on ordering.

Use a queue when work can be delayed, producers and consumers need independent scaling, spikes must be buffered, or processing should happen outside the request path.

Use event streaming when multiple consumers need a durable event history, replay, partitioned ordering, or continuous processing.

Queue checklist

• Delivery guarantees and visibility timeout.
• Retry policy, exponential backoff, and maximum attempts.
• Dead-letter queue and operational replay procedure.
• Idempotent consumer behavior.
• Message size limits and schema evolution.
• Ordering requirements and partition key.
• Queue depth, oldest-message age, and processing rate.

Transactional outbox pattern Write the business change and an outbox event in the same database transaction. A publisher later delivers the event to the broker. Consumers should still be idempotent because publication and delivery can be retried.

Saga pattern Use a sequence of local transactions for a multi-service business workflow. If a later step fails, execute compensating actions where appropriate. Compensation is a business operation, not always a literal rollback.

Backpressure When consumers cannot keep up, bound queues, slow producers, reject excess work, or shed nonessential load. An unbounded queue turns overload into increasing latency and eventual resource exhaustion.

Use synchronous requests when the caller requires an immediate result and the work is bounded. Use asynchronous processing when delayed completion is acceptable and the system can expose status or completion notifications.

Vertical scaling: increase resources on one machine. It is operationally simple but has hardware limits and may preserve a large failure domain.

Horizontal scaling: add instances. It requires traffic distribution, health checks, capacity planning, and usually stateless or externally coordinated application state.

Stateless application servers make horizontal scaling and replacement easier. Store durable shared state in appropriate external systems rather than process memory when requests may land on different instances.

Common bottlenecks

• CPU: optimize algorithms, profile hot paths, parallelize carefully, or add compute.
• Memory: bound caches and queues, inspect leaks, reduce object retention.
• Database: tune queries and indexes, reduce round trips, batch writes, partition when justified.
• Network: reduce payload sizes, reuse connections, move data closer to users.
• Lock contention: shorten critical sections, reduce shared mutable state, or partition contention domains.
• External dependencies: apply timeouts, concurrency limits, caching, and graceful degradation.

Latency percentiles

• p50 describes typical median latency.
• p95 and p99 expose slower experiences and tail latency.
• Averages can hide severe latency outliers.

Little's Law: average work in progress = throughput × average time in the system.

Capacity planning checklist

• Measure per-instance sustainable throughput under realistic load.
• Include peak traffic, dependency limits, and failure headroom.
• Load test normal, peak, and degraded conditions.
• Scale on meaningful signals such as saturation and queue age, not CPU alone.
• Verify that downstream databases and APIs can support added application instances.

Adding more application servers does not solve a bottleneck in a single database, a hot partition, or a rate-limited third-party service.