Why learn system design? Solve problems across the whole service

A school builds a website where parents book a meeting with a teacher. The booking button works in a quiet test. When bookings open to all families, some parents wait a long time, two people try to take the same appointment, and an email failure leaves a parent unsure whether their booking exists.

These problems are not all solved by writing a better button. They involve the application, its saved records, the network and the way it handles failures. Learning system design helps you see those relationships and choose a useful change. It is useful for small applications as well as busy services.

The previous lesson explains the parts of a booking service. We will keep that example and ask why understanding the whole service changes how you solve problems.

Suppose a parent says, “Booking takes too long.” You can follow one request from the browser through the application and database, then back to the browser. For this teaching example, the application also waits for email work before returning its response.

A trace is a record that links the work performed for one request. Timings in that record help you see which steps contribute to the wait. A metric summarises many observations, such as the number of failed bookings in a minute. A log records an event and its context, such as a booking attempt and the error it encountered.

A millisecond, written ms, is one thousandth of a second. Here the total is 150 + 100 + 800 + 150 = 1,200 ms. The database lookup contributes 800 ms, so it is the largest part worth investigating. That does not prove the database product is wrong: the query, stored data or work being requested may need attention.

In a real service, some work overlaps and some requests wait in a queue. Do not add overlapping timings twice. One request also cannot describe every family’s experience: look at repeated observations, failures and busy periods. Google’s service-level guidance explains why measurements should reflect what users care about.

Keep the same invented sequential timings in front of you: network 150 ms, application 100 ms, database 800 ms, email 150 ms. The original total is 1,200 ms.

If you make the application work twice as fast, its time falls from 100 ms to 50 ms. The total becomes 150 + 50 + 800 + 150 = 1,150 ms. That is a small improvement because most of the wait remains elsewhere.

Instead, suppose a test changes the database lookup from 800 ms to 300 ms while all other stages stay unchanged. The total becomes 150 + 100 + 300 + 150 = 700 ms. This calculation gives a reason to investigate the lookup, not a guarantee that a particular optimisation will work.

Write a hypothesis, a claim you can test: “Reducing the availability lookup will shorten the booking response without allowing duplicate appointments.” Try the change on representative data, measure again, and check that the correct records are still returned. See latency and throughput for the difference between request delay and work completed per second.

A server is a computer or running service that handles requests. Adding application servers can spread application work across more places. It does not automatically increase the capacity of a database they all share.

In this model, three application servers could handle up to 3 × 10 = 30 requests per second, but the shared database can complete at most 10 booking writes per second. The complete booking flow therefore cannot sustain 30 new bookings per second. Its upper limit is 10 in this simplified model, and other costs could make the actual rate lower.

The limiting part is called a bottleneck. System design helps you identify it and ask what should change. Perhaps a lookup does unnecessary work; perhaps requests arrive faster than they can be processed. Measure before increasing capacity. Horizontal and vertical scaling explores adding machines versus strengthening an existing one.

Fast responses are not enough if two parents receive the same appointment or a confirmed booking disappears after a restart. A durable booking remains saved despite the failures the storage system is designed to withstand. A reliable service also needs a clear way to respond when a step fails.

Imagine that the booking is saved, but email delivery fails. Deleting the booking just because the email failed would create a different problem. The design should separate the confirmed appointment from follow-up notification, record unfinished delivery work appropriately, and provide a recovery path.

Conversely, if the booking was never saved, sending “Confirmed” would mislead the parent. The order of work and the meaning of success matter. The authoritative-write example shows why the database decision must control who gets the appointment.

Practice these failure cases before a busy launch. Ask what already happened, what the user sees, and what happens after a retry. System design cannot promise that nothing fails; it helps you plan behavior you can test and operate. Learn more about availability and reliability.

A trade-off means a choice improves something while adding a cost, limitation or different behavior. There is no component that makes every part of a service better for free.

A cache keeps a copy of data for quicker reuse. A queue holds work that another part of the system will handle later. More application servers provide additional places to process requests. Each can help a specific problem, but each introduces work you must understand.

A cached appointment list can be helpful, but an old copy must not decide who owns a slot. A queue may let email finish after the booking response, but someone must detect failed delivery and decide how retries work. Additional servers cost money and need deployment and monitoring.

A small team may meet its goal with one well-understood application and a database. Add another component when its benefit justifies the work. The AWS Well-Architected Framework provides a broader way to review operating, reliability, performance and cost considerations.

Read each problem, choose a next step, and compare its consequence with the alternative. In the second scenario, readiness means checking that a newly started application is ready to handle requests before sending it real traffic.

All choices and explanations stay visible. This exercise assembles a decision note; it does not measure a live service, establish a production guarantee or assign a universal score. If new evidence appears, reconsider the choice.

System design gives you a way to discuss a choice with another developer, the school staff or the person responsible for keeping the service running. You do not need to be a senior architect to ask where a booking is saved or what a failure means.

Compare “We need a queue because queues are scalable” with “The parent’s booking response should not wait for email delivery. We will save the appointment first and arrange email as follow-up work, with failed delivery tracked for retry.” The second explanation connects the choice to an actual need and names its new responsibility.

A decision record is a short note describing the problem, evidence, choice and trade-off. For this school, it might say:

• Problem: parents wait while email work finishes.
• Requirement: confirm a saved booking promptly; email may arrive later.
• Choice: separate delivery from the booking response using durable follow-up work.
• Responsibility: detect delivery failures and retry safely.
• Revisit when: staff need immediate delivery guarantees or operating effort becomes too high.

This record helps future teammates understand what the design promises and why it may need to change.

The school example is deliberately small, but the questions transfer to other applications:

• Chat: what happens to a message when the recipient is offline, and how does a sender know it was saved or delivered? Those are different events.
• A URL shortener: how do two different addresses avoid getting the same identifier, and where is the mapping saved so a later visit can find it?
• An online shop: when many people buy the last item, what decides who gets it, and what happens if payment or confirmation fails?

The right answers depend on the service. A content delivery network can help deliver suitable static content; it does not decide who owns an appointment or guarantee that a chat message reaches a particular person. A named database or encoding scheme is also not a complete design.

These questions are useful in everyday development and in design interviews. The skill to practice is explaining your assumptions and reasoning, rather than memorizing a diagram of a famous company. Follow the course’s practical lessons as you build the vocabulary; you do not need every advanced topic before improving a small service.

Your task: use these invented sequential timings: network 150 ms, application 100 ms, database 800 ms, email 150 ms. The school wants the booking response below 900 ms for the representative requests in this exercise, while preventing duplicate appointments. You have time to investigate one change first.

Choose a part to investigate, state what you would measure, and name a correctness check. Do not assume you can skip saving the booking just to return faster.

Worked answer

Investigate the database lookup first because its 800 ms is the largest contribution. Record its timings across representative requests and inspect the work it performs. If a test reduces that stage to 300 ms while the other stages stay unchanged, the predicted total is 150 + 100 + 300 + 150 = 700 ms.

Then measure the complete response, not only the query. Test two simultaneous attempts for the same appointment and verify that at most one receives a confirmed reservation. Repeat with realistic data and busy conditions. A slower result or incorrect booking means the experiment did not meet the goal, even if an isolated function became faster.

The 900 ms target is an exercise assumption, not a universal recommended response time. For a real school, agree on what matters to parents and measure a representative range of requests rather than accepting one fast example.

Learning system design helps you connect a working feature with the service people actually depend on. You can investigate a problem, compare a change with its costs, and explain why it fits the current requirement.

• Follow the request: use evidence to find where time goes or where work fails.
• Check the whole result: faster code matters only if the relevant user experience improves and the answer stays correct.
• Look for shared limits: more application servers do not remove every database or network constraint.
• Plan failure behavior: saved bookings, visible responses and delivered messages are separate events.
• Record the trade-off: name the benefit, added responsibility and assumptions that may change.

Before moving on, explain one small improvement you would test for the school, the evidence behind it, and one reason you might reject it after testing.