Architectural Styles: Monolith to Event-Driven

One codebase, one build, one deployment. Database logic, business logic, and the website are glued into a single unit that ships together. Early Amazon.com ran exactly like this, and it worked until every small change meant redeploying the entire site and one bug could take down the whole store.

You are a small team validating a product, and the overhead of distributed systems would slow you down more than a redeploy ever will.

Splitting into microservices before the monolith has actually caused pain. Premature decomposition buys you network latency, service discovery, and per-service deploys, none of which earns you anything if one team can already ship fast.

The system breaks into services, but they all talk through a shared middleman called an enterprise service bus, a central switchboard routing messages between departments. In 2002 Jeff Bezos mandated that every Amazon team expose its functionality through a service interface, no exceptions. Clunky next to what came later, but the direct ancestor of AWS.

Many internal teams need to expose functionality to each other and you need centralized control over how services communicate.

Letting the bus become a dumping ground of untested transformation logic. If nobody can explain what happens to a message between send and receive, you have built a black box, not an integration layer.

Small, independently deployable services, each one owning its own database. Each can be updated, scaled, or crashed without taking down the others. Netflix is the textbook case: after a 2008 database outage took their whole service down, they spent years breaking the monolith apart so a failure in recommendations never touches billing.

Different parts of your product scale at different rates, and a failure in one should not be allowed to take down the rest.

The distributed monolith: services that all deploy together, share one database, or break the moment another service's schema changes. That is a monolith with network latency, not microservices.

You stop thinking about servers. You write a function, it runs only when triggered by an event, then disappears, and you are billed per execution rather than for idle uptime. Upload an image, a function fires, resizes it, and shuts down. No server was sitting around waiting for that to happen.

The workload is spiky or infrequent, and paying for idle servers between events would be wasted spend.

Putting a latency-sensitive, user-facing endpoint on functions you have never load-tested. Cold starts run a wide range, roughly 150 to 500ms for Python or Node, but multiple seconds for a heavy dependency tree or a VPC attachment. Fine for a background resize, painful for a checkout button.

Services publish events into a stream and listeners react independently. The publisher does not know who is listening, which is what lets a new consumer be added without touching the service that produced the event.

Several unrelated systems all need to react to the same fact in real time, without blocking each other or the thing that produced it.

Assuming the decoupling is free. Tracing one request across many asynchronous consumers is genuinely harder, and ordering guarantees stop being something you get for nothing.