The Interview Framework

The one-sentence loop

Clarify → quantify → define invariants and APIs → choose data ownership → draw the critical path → deepen the bottleneck → break the system → make it operable → migrate it.

Use this loop flexibly. Interviewers may direct you into one area; acknowledge the shift and preserve a small list of deferred questions.

A 60-minute pacing model

Time	Focus	Output
0–7 min	Requirements and scope	Actors, top use cases, non-goals, SLOs, consistency/durability/security constraints
7–12 min	Estimates	Peak requests, bytes, storage growth, connections, fan-out, failure headroom
12–18 min	Contract and data	API/events, idempotency, entities, invariants, access patterns
18–30 min	High-level design	Read/write paths, ownership, major components, regions/failure domains
30–45 min	Deep dive	One or two hard areas with algorithms, state transitions, and numbers
45–55 min	Reliability and evolution	Overload, partial failure, observability, security, migration, cost
55–60 min	Summary	Decisions, trade-offs, residual risks, validation plan

A 45-minute interview uses roughly 5/5/5/10/10/7/3 minutes. Do not spend half the session collecting every possible requirement; prioritize the decisions that would change the architecture.

1. Clarify the product and boundaries

Start with a proposed interpretation rather than an interrogation:

“I’ll design the backend for X, focusing on A and B. I’ll treat C as an external dependency and defer D unless it changes the data model. The primary users are …”

Ask questions in decision-changing groups.

Functional scope

• Who creates, reads, changes, and deletes the core object?
• What are the three highest-value user journeys?
• Is work synchronous, asynchronous, collaborative, scheduled, or offline?
• Which operations need search, ordering, pagination, bulk, or real-time updates?
• What is explicitly out of scope?

Quality and risk

• Peak and average traffic; object size and retention.
• Latency SLO by operation, not one global number.
• Availability target and acceptable degraded modes.
• Durability/RPO and recovery/RTO.
• Consistency and atomicity for each critical invariant.
• Geography, residency, privacy, abuse, and cost constraints.

State the top invariant

A strong answer names the fact the design must never violate:

• A payment operation posts at most once under one idempotency key.
• A username is not committed to two accounts.
• An order cannot move from shipped back to paid without an explicit correction event.
• A document version is immutable after publication.

This invariant directs storage, transaction, partition, and failure choices.

2. Quantify before selecting components

Write units and ranges. Prefer a transparent approximation to a magical precise number.

Minimal estimate set

1. Peak reads and writes per second.
2. Average and p95 payload size; ingress and egress bytes/s.
3. Daily/new storage and retained total, including indexes/replication.
4. Concurrent in-flight requests or long-lived connections.
5. Fan-out, partitions touched, or downstream amplification.
6. Capacity after the largest planned failure.

Example:

Peak messages = 50,000/s
Average encoded message = 1.5 KiB
Raw ingress = 75 MiB/s
Replication factor 3 => ~225 MiB/s broker write traffic before overhead
30-day retention => ~185 TiB raw replicated payload
Largest tenant = 6% => 3,000 messages/s on one key unless bucketed

3. Define contracts before boxes

Synchronous API

Specify method/operation, resource identity, request/response, authorization scope, idempotency, pagination, errors, and timeout/retry contract. A strong API distinguishes:

• invalid request;
• unauthorized versus forbidden;
• conflict/precondition failure;
• accepted for asynchronous processing;
• rate limited with retry guidance;
• transient dependency failure;
• ambiguous timeout where operation status must be queried.

Asynchronous contract

Specify command/event semantics, authoritative producer, event ID, entity/order key, schema version, delivery, retention, and consumer idempotency. For long work, return a job resource with state, progress, result, cancellation policy, and expiry.

Data model

List entities and relationships, but spend more time on:

• stable keys and tenant scope;
• immutable facts versus mutable projections;
• uniqueness and state-transition constraints;
• transaction/aggregate boundary;
• access patterns and result bounds;
• retention and deletion;
• version used for optimistic concurrency or replay.

4. Draw the critical paths

Draw a small number of components and narrate one write and one read. Use arrows labeled with protocol and semantics—not just component names.

flowchart LR
    C[Client] -->|HTTPS + idempotency key| G[API gateway]
    G --> S[Owning service]
    S -->|transaction: state + outbox| DB[(Primary database)]
    O[Outbox relay] --> Q[(Event log)]
    Q --> P[Projection worker]
    P --> R[(Read model)]
    C -->|read| G
    G --> R

For the write, say when success is returned and where the durable copies exist. For the read, say what freshness it provides. Identify the source of truth and every derived copy.

Component test

For every box, answer:

1. Why does it exist?
2. What key routes/partitions its work?
3. What guarantee does it provide?
4. What is its first likely bottleneck?
5. What happens when it is slow, unavailable, or stale?

Remove boxes that have no justified answer.

5. Choose a deep dive strategically

Good deep dives sit where requirements conflict:

• uniqueness versus multi-region write availability;
• order versus parallelism;
• cache freshness versus origin protection;
• one transaction versus asynchronous workflow;
• shard locality versus hot-tenant distribution;
• WebSocket affinity versus failover;
• exact analytics versus cost/latency;
• privacy deletion versus immutable retained logs.

Use a repeated structure:

1. State the invariant/goal.
2. Present two or three alternatives.
3. Select one using workload evidence.
4. Trace normal state transitions.
5. Trace timeout/crash/partition after each transition.
6. Add metrics and repair.
7. State the limit and next evolution.

6. Reliability is more than replicas

Cover at least one example in each category.

Overload

• Bounded queues and connection/concurrency limits.
• Admission control, tenant quota, priorities, and load shedding.
• Retry budgets with exponential backoff and jitter.
• Autoscaling signal that reflects work: queue age, CPU cost, bytes, partitions.

Partial failure

• Timeout and deadline propagation.
• Ambiguous success and idempotency.
• Circuit breaking and fallback.
• Stale cache/replica behavior.
• Split brain prevention through terms, quorum, leases, and fencing.

Data recovery

• Replication acknowledgment and RPO.
• Backup plus tested restore speed and RTO.
• Rebuild of derived stores from retained truth.
• Reconciliation/checksum/inventory processes.

Deployment and migration

• Backward-compatible schema/API/event changes.
• Expand/backfill/validate/switch/contract.
• Canary, feature flag, shadow/dual read, and rollback boundary.
• Capacity during migration and largest failure.

7. Observability as a design output

Do not say “add monitoring.” Give a compact operational contract.

Golden user signals

• Success rate by operation and error class.
• Latency percentiles and deadline misses.
• Freshness/age of data or asynchronous completion.
• Correctness/reconciliation discrepancies.

Saturation and internals

• CPU, memory, connection pools, run queue.
• Per-shard/partition QPS, bytes, storage, and max-to-mean skew.
• Cache hit ratio by status/tenant/object; origin load.
• Queue lag and oldest item; retry/DLQ.
• Replication apply/log lag and recovery progress.

Tracing and identity

Carry request ID, trace ID, user/tenant, idempotency/operation ID, entity ID, event ID, and deployment/config version where safe. These identifiers let an operator reconstruct one business action across retries and asynchronous stages.

8. Security, privacy, and abuse

A senior design treats these as architecture:

• authentication versus authorization at object/tenant boundary;
• least-privilege service identities and secret/key management;
• input size, decompression, parser, query, and fan-out bounds;
• rate limits by user, tenant, IP/device, and expensive operation;
• encryption in transit/at rest and audit access;
• sensitive fields in logs, events, URLs, caches, and analytics;
• deletion/retention/legal-hold workflow across replicas and derivatives;
• isolation against noisy neighbors and cross-tenant cache/index leaks.

9. Cost and operability

Identify dominant units: CPU-seconds, stored GiB-month, IOPS, requests, egress, cross-region bytes, cache memory, broker retention, or operator complexity. Discuss one cost reduction and its trade-off.

Include ownership: who runs this at 03:00, how they diagnose it, what can be paused, and which admin path remains available during overload. Simple systems often win until a measured requirement justifies additional stores or asynchronous views.

10. Close like a senior engineer

Use the final minutes to make the architecture legible:

“The design keeps X as the authority, partitions by Y, and acknowledges writes after Z. Reads use A with a B freshness contract. The main scale risk is C, mitigated by D; the main correctness risk is E, handled by F. During region isolation we do G. I would validate H with a load/failure test before committing, and the next evolution at threshold J is K.”

Reusable interviewer follow-ups

After any initial design, expect:

• What breaks at 10× load? At 100× data?
• What happens to an in-flight write when the primary dies?
• How does a user read their own write?
• Which operation is not idempotent, and what does a timeout mean?
• What is the hottest key/tenant/object?
• How do you add a shard or region online?
• How do you delete one user from all copies?
• What does the on-call see first?
• Which SLO do you sacrifice during overload?
• How do you prove the derived view is complete?
• What would you simplify for a team of five?
• What evidence would make you reverse the main decision?

Anti-patterns in interview delivery

• Starting with Kafka, Redis, or microservices before requirements.
• Treating averages as capacity and ignoring peak/failure/skew.
• Saying “eventual consistency” without a freshness or conflict contract.
• Claiming exactly once across an external side effect.
• Adding replicas without defining acknowledgment and failover.
• Adding a cache without key, TTL, invalidation, and stampede behavior.
• Sharding without a move/reshard path.
• Describing normal operation for 50 minutes and failures for 30 seconds.
• Listing technologies instead of tracing state transitions.
• Refusing to choose. State assumptions and make a reversible decision.

Blank interview canvas

Problem / scope:
Actors and top journeys:
Non-goals:
Peak scale and growth:
Latency / availability / RPO / RTO:
Critical invariants:
Consistency and degraded behavior:
API / events / idempotency:
Entities, keys, access patterns, retention:
Write path and acknowledgment:
Read path and freshness:
Partitioning / replication / cache:
Hard deep dive:
Overload / partial failure / recovery:
Security / privacy / abuse:
Observability:
Migration / rollout / rollback:
Cost / operational ownership:
Summary and open validations: