177: System Design - Requirements and Scale
Learning outcomes
- clarify actors, use cases, and non-functional requirements;
- estimate rough traffic and storage;
- identify the first bottleneck without premature infrastructure.
Practice
Design a task-sharing service. Write assumptions, read/write ratios, latency goals, retention, authorization rules, and capacity estimates before drawing components.
Checkpoint
Explain which requirements are uncertain, which estimate most affects design, and what evidence would change the architecture.
Estimation example
If 100,000 users each create 5 tasks per day, that is 500,000 writes per day, about 6 writes per second on average. Peak traffic might be 10 times higher, so state the 60 writes-per-second planning assumption rather than presenting it as fact. Estimate storage from record size, retention, indexes, and replication; round numbers are useful only when assumptions are visible.
Worked requirements pass
Ask whether users share by workspace, whether edits need real-time visibility, the maximum task size, deletion/retention rules, and the expected read/write ratio. A first API might be POST /workspaces/{id}/tasks, GET /workspaces/{id}/tasks?cursor=..., and PATCH /tasks/{id}. Authorize workspace membership on every access; never treat an id in the URL as permission.
For the estimate above, 500,000 task records/day at 1 KB each is roughly 0.5 GB/day before indexes and replicas, or about 182 GB/year. A relational store is a reasonable starting point for ownership and transactional updates; a document store can fit denormalized, document-shaped reads. Choose from access patterns, not product labels. Add a cache only after naming its key, TTL, invalidation, and stale-read policy.
Scoring and edge cases
Score 2 points each for clarified scope, visible arithmetic, API/data model fit, authorization, consistency choices, and bottleneck reasoning. Check empty workspaces, cursor expiry, deleted users, duplicate retries, concurrent edits, very large pages, and clock/time-zone fields. Record which estimate would change the design first.
Review questions
What must be strongly consistent? What can be eventually consistent? Which limit is a product decision rather than an infrastructure fact?