Delivery framework

Put a clock where you can see it. Say the time checks out loud. The point of a framework is not ceremony. It is a rail you can grab when you are nervous, so you still finish a working system.

Two clocks

Minutes	45-minute loop	60-minute loop
Opening	0–4 requirements	0–6 requirements
Contract	4–7 API	6–12 API
Data	7–11 entities, keys, two indexes	12–18 entities and the access path
Picture	11–20 draw and walk a read and a write	18–35 simple design that meets the API
Pivot	20–25 three failure modes, offer a deep dive	35–40 name the bottleneck
Depth	25–45 one hard problem, still drawing	40–60 two deep dives

If you are slow, cut features, not the drawing. A narrow design you finished beats a wide design you narrated.

Requirements

Functional requirements are “a user can…” sentences. Write three to five. Ask at most two questions, state assumptions, and move. A long list feels thorough and then traps you into designing the long list.

Non-functional requirements are quantified and local. “Low latency” is not a requirement. “Redirects return in under 50 ms at the edge” is. Pick the ones that will change the design:

• Consistency or availability when a partition or a dependency fails.
• Read-heavy or write-heavy, and whether traffic is bursty.
• The latency budget of the one request a human is waiting on.
• Durability. A lost tweet is rude. A lost payment is an incident.
• Cost, when the expensive step is a model call or a sandbox.
• Security and tenancy, when the data is resumes, recordings, or card data.

Do capacity math only when the number picks a component. “Can the hot set fit in Redis?” and “Is the token budget 25 hours or 25 days?” are useful. “So it is big” is not.

Entities, then the API

Entities are the nouns you will store and return. A short list is a first draft: User, Tweet, Follow. You will add columns later, next to the database, when you know which request writes them. Good names matter. Interviewers notice when every table is data.

Default the external API to HTTP and resources that are plural nouns. Take the caller identity from the session, not from a user id in the body. Mark writes with an idempotency key. Say which calls are synchronous.

POST /v1/tweets          { text }            -> 201 Tweet
GET  /v1/feed?cursor=    -> Tweet page
POST /v1/follows         { followee_id }     -> 204

Reach for gRPC between your own services when you own both sides and the payload is chatty. Reach for GraphQL only when you truly have many client shapes and you are willing to talk about the N+1 problem. For server push, design the request API first, then add SSE or WebSockets as a separate path.

Data flow, when the system is a pipeline

Skip this for a CRUD product. Use it when the interesting part is a sequence: crawl, transcribe, grade, publish. Five or six steps, each with an input and a durable status, is enough. That list becomes the queue stages in the drawing.

High-level design

Draw boxes a teammate could implement: client, gateway, service, database, cache, queue, worker, object store, model host. Walk one read and one write. When the walk touches storage, write the columns and the index that make that query fast. Note caches and queues with a verbal “I will come back to this” instead of designing them in the first pass.

A simple sentence keeps you honest: “If this dependency is down, the user sees ___.”

Deep dives

Lead with the non-functional requirement your simple design fails. For a feed, that is fan-out. For tickets, that is two buyers and one seat. For grading, that is a model that returns a score you cannot trace to a quote in the transcript.

Junior interviewers will point at the weak spot. Senior candidates should point at it first, then pause long enough for the interviewer to choose. Do not monologue over the person who has a rubric to fill.

flowchart LR
  A[Requirements] --> B[API and entities]
  B --> C[Draw the simple system]
  C --> D[Walk one read and one write]
  D --> E[Name three failures]
  E --> F[Deep dive on the one they pick]