Part 8 of 8 ยท week 8 of the learning path
The capstone has each team design a new system from a one-line brief, using the same six steps as the case studies, and the final assessment checks that everyone can apply the ideas to fresh scenarios.
Capstone brief. Pick one, or have the trainer assign it:
- A photo sharing feed for 50 million daily users.
- A ride-hailing service that matches riders to nearby drivers.
- A file sync service like a cloud drive.
- A notification service that sends push, email and SMS at scale.
- A distributed rate limiter used by many services.
Deliverables: a design document of up to four pages following the six steps, one architecture diagram with numbered steps, and a 15-minute presentation followed by 10 minutes of questions.
Pacing for a 45-minute design interview or review
| Minutes | Step |
|---|---|
| 5 | Clarify requirements and scope |
| 5 | Estimate load and storage |
| 5 | Define the API and data model |
| 10 | Draw the high-level design |
| 15 | Deep dive on the two or three hardest parts |
| 5 | Trade-offs, failures and monitoring |
Common mistakes: skipping requirements, designing without numbers, leaving a single point of failure, ignoring duplicates and retries, forgetting how it will be monitored, and choosing exotic technology without a reason.
Capstone rubric (100 points, pass mark 70)
| Criterion | Points | What good looks like |
|---|---|---|
| Requirements and scope | 15 | Functional and non-functional needs are explicit, with scope limits stated |
| Estimation | 15 | Numbers are reasonable, shown, and used to drive choices |
| Architecture and data model | 25 | A clear diagram, sensible components, API and data model that fit the requirements |
| Deep dives | 25 | Consistency, scaling and failure handling are worked through for the hardest parts |
| Trade-offs and operations | 20 | Alternatives are weighed, and monitoring, security and cost are addressed |
Final assessment (12 scenario questions, pass mark 9, Architect level needs 11)
- A photo app has 50 million daily users who each upload 2 photos of 3 MB a day. About how much new storage is needed per day before replication?
- A) 30 TB
- B) 300 TB
- C) 3 PB
- D) 3 TB
- Which pattern keeps a multi-service order consistent without a distributed transaction?
- A) A saga with compensating actions
- B) A shared lock across services
- C) A bigger database
- D) Retrying every step forever
- A service must guarantee that a database update and the matching event are both recorded. What should it use?
- A) Publish the event first, then update the database
- B) Update the database, then publish in a separate step
- C) A bigger queue
- D) The outbox pattern: write both in one transaction and publish from the outbox
- A chat message reaches the server twice because the client retried. How do you avoid showing it twice?
- A) Compare timestamps
- B) Ignore all retries
- C) Deduplicate by a client-generated message ID
- D) Increase the timeout
- A new video loads slowly for its first viewers but fast for later ones. Why?
- A) Disk wear
- B) The first request fills the edge cache from the origin and later requests hit the cache
- C) DNS caching
- D) Encoding finishes later
- Two refund requests for the same payment arrive at the same moment. What stops the system refunding more than was paid?
- A) Hope they do not collide
- B) Separate caches
- C) Eventual consistency
- D) A transaction on a versioned or locked payment row, so the second request sees the first refund
- A user updates their profile but sees the old value on reload. What is the likely cause and fix?
- A) Reading from a lagging follower; read your own writes from the leader
- B) A browser bug; clear cookies
- C) Too few indexes; add more
- D) Encryption; turn it off
- A table keyed by timestamp has one overloaded partition. What is the best fix?
- A) Give that partition larger disks
- B) Add more replicas
- C) Hash or combine the key so current writes spread across partitions
- D) Delete old data
- Two services always deploy together and share a database. What is this?
- A) An ideal microservices design
- B) A distributed monolith; merge them or redraw the boundaries
- C) A gateway problem
- D) A replica problem
- The card network times out on an authorization. What should the payment service do?
- A) Mark it processing and check its status or reconcile before any retry
- B) Retry the authorization at once
- C) Tell the customer it failed and refund
- D) Delete the payment
- Peak traffic is 3 million requests per second. Each server can handle 5,000 per second, and you run servers at 50% of that. About how many servers are needed?
- A) 600
- B) 300
- C) 2,400
- D) 1,200
- Events for the same order arrive out of order at a consumer. What is the best design?
- A) Turn off the broker
- B) Add more consumers
- C) Key by order ID so they share a partition, and use version numbers to ignore stale events
- D) Make the messages smaller
Final assessment answers
Sources and further reading
- System Design Primer, with more practice problems and sample solutions for capstone ideas.
- Designing Data-Intensive Applications, for checking consistency and failure reasoning in deep dives.
- Timeouts, retries, and backoff with jitter, for the failure-handling part of the rubric.
Resources
- Designing Data-Intensive Applications by Martin Kleppmann, the main reference for Modules 3 and 4.
- Building Microservices by Sam Newman, for Module 2.
- System Design Interview by Alex Xu, for more worked designs.
- Site Reliability Engineering from Google, for reliability and monitoring practice.
- Stripe documentation on idempotent requests and on webhooks, for Module 7.
The real-world figures in the case studies (message volume, hours uploaded and watched, connection counts) come from public statements and engineering write-ups and are used as inputs for exercises. Trainers should check the current numbers before each cohort.
``
Top comments (0)