What is System Design?

Imagine a small appointment-booking service. A customer sees available times, chooses one and receives a confirmation. The screen is only one part of the service: something must check availability, save the booking and make sure another customer cannot take the same time.

System design decides how these parts work together to meet the user’s needs. It includes where information lives, how requests travel, how failures are handled and how the system is operated. The design may be one application and one database; it does not need to begin with many services.

Begin with a user action: “book Tuesday at 10:00.” The browser or app sends a request to an application. The application checks who may book, validates the time and asks the database to save the reservation.

A database stores records the service needs later. A request asks another component to do something; a response reports its result. These names describe roles, not mandatory separate machines.

Draw arrows and label what moves along them. “Save booking” is more useful than an unexplained line. Mark which step must succeed before the user sees a confirmation. A good diagram explains behaviour, not just a collection of product logos.

Two customers can both see the same available time before either booking finishes. Checking availability on the screen is therefore not enough. The saved reservation needs a rule that prevents both requests from owning that time.

For this example, a database uniqueness rule and a correctly handled transaction can enforce one booking for one slot. A transaction groups related data changes under the database’s guarantees. The application must handle a conflict and tell the second customer the slot is no longer available.

Keep the booking in durable storage before reporting success. A process’s memory can disappear on restart. Confirmation emails and convenient cached lists can be derived from the saved booking, but are not substitutes for the booking record.

Explore two choices for the same small service. The cards show what each choice implies. Select an option in both scenarios and read the combined design note.

For this lesson, a confirmed reservation must survive an application restart. Email delivery may happen later, but the user must receive an honest booking result. The exercise changes a design note, not a running database.

A database failure, a slow network or an unavailable email provider can interrupt the journey. State what the user sees, which work has already happened and how the service recovers.

A missing response does not prove the operation failed. If the booking committed but the response was lost, repeating the request needs to recognise the same intended action or safely check the saved result. This is part of retry and duplicate-handling design.

Look beyond the happy path. A service needs deployment, logs and metrics, backups and a way to investigate incorrect behaviour. More components add more relationships to understand; add them when a requirement justifies the work.

A notebook, a diagram tool and a short decision record are enough to begin. Write the problem, assumptions, chosen approach, alternatives and the main cost or limitation. Someone else should be able to follow the reasoning without hearing the original conversation.

The C4 model offers diagram views at different levels of detail. Azure’s architecture guidance connects requirements with architecture choices. These are references for communicating and evaluating designs, rather than instructions to use every cloud component. Official sources checked 6 October 2026.

Use capacity estimation when volume matters, and measure actual behaviour when choosing software or hardware. A box labelled “database” does not state its guaranteed throughput.

Use the design-pattern guide to distinguish local object structure from service-level coordination. The difference matters when a diagram promises durable or cross-process behaviour.

System design connects a user’s action with the components, data and operations that make it work. Trace one request, choose where the authoritative result lives and describe failures as carefully as success.

Start with the simplest arrangement that meets the requirements. Explain the choices, validate their assumptions and add complexity when it solves a concrete problem.