Monolith vs SOA vs Microservices vs Event-Driven
System Design

Monolith vs SOA vs Microservices vs Event-Driven

Subtitle: One axis explains all four - coupling.

Panel 1 (full width) - THE COUPLING RAIL: four numbered boxes left to right with an arrow rail beneath labeled LOOSER COUPLING, MORE MOVING PARTS. 1 MONOLITH - one deploy, one DB, in-process calls. 2 SOA - few large services, shared ESB bus. 3 MICROSERVICES - many small services, DB each. 4 EVENT-DRIVEN - services emit events, no calls.

Panel 2 - HOW THEY TALK: 1 Function call inside one process. 2 ESB routes and transforms messages. 3 Direct HTTP or gRPC request. 4 Publish to a broker, subscribe later. 4 Sender never knows the receiver.

Panel 3 - USE IT WHEN: 1 Small team, one domain, early product. 2 Legacy estate, many protocols to bridge. 3 Many teams shipping independently. 4 Fan-out, spikes, audit trails, async work. Team count decides more than traffic.

Panel 4 - COST YOU PAY: 1 One bad deploy stops everything. 2 The ESB becomes the bottleneck. 3 Network calls, retries, tracing needed. 4 Eventual consistency everywhere. 4 Debugging means replaying events.

Warning note - COMMON MISTAKE: Splitting into microservices before you have team boundaries and clear domains. You get a distributed monolith: same coupling, plus network failures.