Types of System Design: High-Level vs Low-Level

When discussing a delivery service, a product teammate may need to see how customers place orders and how the application reaches storage. A developer implementing order creation needs more detail: fields, validation, transactions and error handling.

High-level design explains major parts, responsibilities and relationships. Low-level design explains enough internal detail to implement a particular part correctly. The names do not mean good design and bad design; they describe the level of detail appropriate to a question.

A high-level delivery-service view might contain a customer app, an order application, a database and an external notification provider. Label which part creates an order and where the authoritative result is stored.

Include the details needed for the decision: trust boundaries, synchronous waits, deferred work or a critical failure path. Synchronous here means the caller waits for the result. Deferred work can finish after the initial response and needs separate status and recovery behaviour.

A broad diagram may omit internal classes and field names. It should still state relevant assumptions such as expected demand, required durability and acceptable notification delay. High-level does not mean vague.

For order creation, define required fields, validation rules and the stored records. Describe which changes must commit together, how a duplicate action is recognised and what response each outcome produces.

A sequence diagram follows calls in order. A schema describes the structure of stored data. Function or module interfaces describe inputs, outputs and responsibilities. Choose the representation that exposes the difficult behaviour.

Do not invent detail just to fill a template. Include enough to resolve the real ambiguity. If two engineers could implement incompatible retry behaviour from the same description, the description needs a clearer contract.

Imagine two reviews of the same delivery service. Select what to bring to each review. The consequences describe what the audience can judge from that material.

There is no mandatory document size. The point is to keep the service promise clear while changing the detail needed to evaluate it.

If the overview says “reply after the order is saved,” the detailed flow must not send success before commit. If the overview promises retry safety, the schema and transaction path need a way to support it.

Update the views when decisions change. A diagram that describes yesterday’s behaviour can mislead both an implementer and the person diagnosing an incident. Keep decision notes close to the code or documentation people actually use.

A design review can move between levels. Begin with the service goal, zoom into the risky operation, then return to how that behaviour affects the whole service. You do not have to complete every broad diagram before learning anything about implementation.

The C4 model offers context, container, component and code views. In that vocabulary, a container is a separately runnable application or data store; it does not necessarily mean a Docker container. Choose relevant views and explain the terms to your audience. Official source checked 6 October 2026.

For a beginner, a labelled request journey and a small call sequence can communicate more than a dense notation. Explain a symbol once, keep arrows directional and say what each arrow carries.

A diagram is a communication aid. Check it against requirements, actual interfaces and experiments. Its visual neatness does not prove correctness or performance.

Use the pattern-family guide to decide whether the issue is construction, object collaboration or service coordination. Builder addresses construction; Sidecar addresses deployment support.

High-level design explains the major relationships. Low-level design makes a specific responsibility implementable. Both need clear assumptions and consistent promises.

Choose the zoom for the audience, expose the difficult behaviour and update the views when the implementation or requirements change.