10.2 Common cloud architecture patterns

What this is and why it exists

Most business problems are one of a small number of shapes, and knowing the shapes means you can sketch a workable architecture in ten minutes instead of inventing one over a fortnight. This lesson is those shapes: what each is made of, what it is good at, where it breaks, and — the part that matters most for a first system — which one to reach for when you are not yet sure what you are building.

The vocabulary

• Static site — pages served as files, with no server-side code.
• API tier — the layer holding your logic, called by the front end.
• Managed database — the store, run by the provider.
• Asynchronous — work accepted now and done later, so the caller does not wait.
• Worker — a process that takes accepted work and performs it.
• Event-driven — components reacting to things that happened rather than being called directly.
• Fan-out — one event causing several independent reactions.
• Publisher and subscriber — the component announcing an event and the ones listening for it.

The mental model

The first pattern is the one most systems should be. A static front end on object storage behind a content network, an API tier on a managed platform, and a managed database in a private subnet. It is cheap, it is understood by everyone, it scales further than most products ever need, and it has three components to reason about when something breaks. If you are unsure what to build, build this. Most of the architectures people regret were reached by adding cleverness to this one before it had a demonstrated problem.

The second pattern arrives when a request must not wait. Some work is slow or unreliable in ways a user should not sit through: a video to encode, a report to build, an email to send, an external service to call. The shape is the same everywhere — the API accepts the request, writes a job onto a buffer, returns immediately with something the caller can check later, and a separate worker takes jobs and does them. It buys three things: users get an instant answer, a slow or absent downstream turns into a delay rather than an error, and the worker can be scaled independently of the API. It costs three: the work is no longer immediate, you now need somewhere for progress and results to be reported, and — because delivery is at-least-once — the worker must tolerate seeing the same job twice, which is the idempotency rule from the previous lesson arriving exactly where you were told it would.

The third is event-driven, and it is the second one generalised. Instead of one component handing work to one other, a component announces that something happened and any number of others react. An order is placed: one subscriber charges the card, another updates stock, a third sends a confirmation, a fourth records it for analysis. That is fan-out, and its value is that adding the fifth reaction requires no change to the thing that announced the event. Its cost is that no single place describes what happens when an order is placed — the flow lives across the subscribers, so understanding the system means finding all of them. Use it where the reactions are genuinely independent, and be honest that if all four must succeed together you have wanted a transaction all along.

Then the honest sequencing advice, which the checkpoint names and which is worth stating plainly: monolith first. Start with one deployable application, well-structured inside, with clear boundaries between modules. Boundaries are cheap to move inside one codebase and expensive to move once they are network calls, and you do not know where they belong until the product has told you. Split later, when a specific piece has a specific reason — it scales differently, it changes far more often, it needs a different language, or a separate team genuinely owns it. Each of those is a real reason. "Microservices are modern" is not, and it is the most expensive sentence in this module.

What you should now be able to explain or do

Draw the three-component pattern and say what each piece is. Say when to reach for asynchronous processing and name its three benefits and three costs. Explain fan-out and what it makes cheap and what it makes hard. Say what monolith-first means and give three specific reasons that justify splitting something out. Sketch a workable architecture for a described business problem in a few minutes and defend each choice.

Check yourself