Monolith vs Microservices vs Event-Driven: which architecture fits?

This is a <strong>decision guide</strong>. It explains the real tradeoffs between:

• <strong>Monolith</strong> (one deployable application)
• <strong>Microservices</strong> (many independently deployable services)
• <strong>Event-driven architecture</strong> (services react to events; often combined with microservices)

It’s not just definitions—each section calls out:

• operational complexity
• scaling behavior
• failure modes
• data consistency challenges
• when it becomes a “bad idea”

One codebase, one (or a few) deployables.

• Pros: simple, fewer moving parts
• Cons: scaling and change isolation can be harder as it grows

Many services with clear boundaries, each deployable independently.

• Pros: independent scaling &amp; deployments
• Cons: distributed systems complexity: networking, retries, observability, data consistency

Components communicate by publishing <strong>events</strong> and consuming them.

• Pros: decoupling in time and place, easier propagation of changes
• Cons: async complexity, ordering issues, eventual consistency, “what happened?” debugging

&gt; Important: “event-driven” is a <strong>communication style</strong>. You can do event-driven with a monolith too, but in practice it’s often used with microservices.

The central question is:

• Monolith: you avoid coordination by keeping everything together.
• Microservices: you reduce coupling by splitting, but pay with coordination.
• Event-driven: you reduce coordination in request/response paths by using async events, but you pay with causal reasoning.

A useful framing:

• <strong>Monolith</strong> optimizes for <strong>team speed early</strong>.
• <strong>Microservices</strong> optimize for <strong>organizational speed as teams grow</strong>.
• <strong>Event-driven</strong> optimizes for <strong>system responsiveness &amp; decoupled change</strong>.

• one repo (maybe modular packages)
• one database (often)
• one deployment artifact

• early product / small team
• you want fast iteration
• your biggest bottleneck is feature delivery, not scale isolation
• you can keep strong modular boundaries inside the codebase

• strict module boundaries
• clear ownership of domains
• do not let modules call each other randomly
• use a single “integration layer” for external systems

You scale by:

• adding more instances of the whole app
• optimizing queries
• caching

This can become expensive when only one domain needs heavy scaling.

Microservices aren’t just “many repos”. They require:

• clear ownership boundaries
• independent deployment
• resilient communication patterns
• observability (logs + metrics + traces)

If you don’t have those, microservices become *distributed monoliths*.

• multiple teams need to ship independently
• you have clear domain boundaries
• traffic is uneven (one area needs scaling without scaling the whole app)
• you can invest in platform capabilities (CI/CD, tracing, service discovery, auth, retries)

• <strong>Synchronous call chains</strong> (requests that call 5 services in a row)
• <strong>No timeouts / retries</strong> → cascading failures
• <strong>No idempotency</strong> → duplicates break business operations
• <strong>No distributed tracing</strong> → debugging becomes guesswork

For idempotency patterns: see <strong>idempotency-in-distributed-systems</strong>.

Most real systems end up with:

• per-service databases
• eventual consistency across boundaries

Common approaches:

• outbox pattern
• sagas
• careful read models

Instead of:

• Service A calls Service B and waits

You do:

• Service A publishes an event like <code>OrderPlaced</code>
• Service B consumes it like “Update inventory”

This shifts the system from request/response coupling to <strong>change propagation</strong>.

• you need to react to business events (order placed, user registered)
• you need decoupling between teams/domains
• you want to fan out changes to multiple consumers
• you have background workflows that don’t need immediate synchronous response

• <strong>Ordering</strong>: events may arrive out of order
• <strong>Duplication</strong>: at-least-once delivery is common
• <strong>Causality</strong>: “why did this happen?” needs correlation

This is where correctness patterns matter:

• <strong>idempotent consumers</strong>
• deduplication keys
• retry policies
• replay tooling

For deeper semantics: see <strong>exactly-once-semantics-myths</strong>.

Typical patterns:

• publish events after a successful state change
• use the <strong>outbox</strong> to avoid “DB updated but event lost”
• model changes as a sequence of events

• One team, releasing monthly? → start with monolith.
• Multiple teams, deploying weekly? → consider microservices.
• Many teams reacting to each other’s changes? → event-driven helps.

• Whole app scales together → monolith is efficient.
• Only certain domains scale differently → microservices (or at least isolate those domains).

• Need fast synchronous response to the user → monolith or microservices with careful RPC.
• Can handle async workflows (emails, reports, projections) → events.

• Strong consistency everywhere → monolith (or limited distributed consistency).
• Business can tolerate eventual consistency → microservices + events.

• If you don’t yet have tracing, SLOs, and incident playbooks, microservices will hurt.

Most mature systems look like:

• <strong>Monolith first</strong> (to learn domain and ship)
• <strong>Modular monolith</strong> (organize code internally)
• Extract the hardest domains into <strong>microservices</strong>
• Add <strong>event-driven</strong> flows for background processing and decoupling

This hybrid approach avoids the “big bang rewrite” trap.

Let’s say you have:

• checkout
• inventory updates
• order confirmation email
• analytics projections

• one app updates everything in one DB transaction (if needed)
• email/analytics may still be async jobs but within the same deployment

• checkout service writes order data
• inventory service updates stock via API call (synchronous) or async
• email service triggers email

• checkout publishes <code>OrderPlaced</code>
• inventory consumes it and updates stock
• email consumes it and sends confirmation
• analytics consumes it and updates read models

Result: decoupled changes, fan-out, fewer synchronous dependencies.

1. Start with a <strong>modular monolith</strong>.
2. Identify hotspots (slow DB queries, noisy domains, frequent changes).
3. Extract <strong>microservices only where boundaries are real</strong>.
4. Introduce <strong>events</strong> for domain propagation and async workflows.
5. Build correctness primitives early: idempotency, retries, observability, deduplication.