A strong system design answer is a sequence of decisions, not a tour of every technology you know. Use the clock to make your reasoning visible.
Minutes 0-5: clarify the problem
Confirm users, core actions, consistency needs, latency expectations, geography, and what is explicitly out of scope. Write down the three requirements that will drive the architecture.
Minutes 5-10: estimate the load
Use rounded assumptions for requests per second, storage growth, object size, and read-to-write ratio. The goal is to expose scale-sensitive choices, not to perform perfect arithmetic.
Minutes 10-25: draw the first complete path
Show clients, APIs, data stores, queues, caches, and the main read and write flows. Start simple. Name the failure boundary and the source of truth.
Minutes 25-38: go deep where it matters
- Partitioning and hot-key risk
- Consistency and duplicate processing
- Cache invalidation and stale reads
- Backpressure, retries, and dead-letter handling
Minutes 38-45: close with tradeoffs
Summarize the design, the biggest risk, what you would measure, and the next improvement you would make with more time. Interviewers remember a clear close.