Everyone seems to be returning to the monolith, but event-driven microservices are still the right choice for high-scale infrastructure. We’ve built the tooling and aligned our teams. We’ll be here when the pendulum swings back.

Clint Edwards — Tue, 30 Jun 2026 13:37:58 +0000

Clint Edwards

Jun 29

The Microservices Exodus: Why We’re Not Leaving

#distributedsystems #architecture #microservices #eventdrivenarchitect

6 min read

The Microservices Exodus: Why We’re Not Leaving

Clint Edwards — Wed, 20 May 2026 17:40:08 +0000

Everyone seems to be consolidating. Here’s why we’re staying the course on microservices and event-driven architecture.

The Backlash Is Real

Over the past two years, a quiet but growing chorus of engineering leaders have been publishing post-mortems with a familiar headline: ”We’re moving back to the monolith.”

Amazon Prime Video made waves in 2023 when they detailed migrating a distributed microservices pipeline to a monolith, cutting infrastructure costs by 90%. Shopify doubled down on their “modular monolith.” Stack Overflow never left. DHH declared microservices a “cargo cult.” And a wave of CTOs nodded along.

The critique is fair. Microservices, when done poorly, introduce a staggering amount of operational overhead: distributed tracing across dozens of services, network latency compounding at every hop, the cognitive burden of eventual consistency, and the sheer infrastructure cost of running hundreds of containers for what could be a simple CRUD app.

These are legitimate complaints. And for many teams, the consolidation makes sense. A distributed architecture, in many of these cases, was simply the wrong choice.

What the Backlash Is Actually About

The teams retreating from microservices are overwhelmingly retreating from premature microservices : services decomposed too early, too granularly, without the organizational structure or domain knowledge to justify the split.

Conway’s Law cuts both ways. If your team isn’t structured to own independent services, your architecture will betray you. A microservices architecture operated by a monolithic team is the worst of both worlds: distributed complexity with centralized bottlenecks.

The problem was never microservices. The problem was applying microservices to problems that didn’t warrant them, or doing so without the event-driven infrastructure needed to make them compose cleanly.

Event-Driven Architecture Changes the Calculus

The teams that struggled most with microservices were the ones coupling services together synchronously. REST calls chaining through five services, each one a failure domain, each one compounding latency. That’s not a microservices problem; that’s a synchronous integration problem wearing microservices clothing.

When services communicate through events (asynchronous and durable), the failure modes change entirely. A service going down doesn’t cascade; it just falls behind. A new consumer can subscribe to an existing event stream without touching the producer. Business logic can evolve independently because the coupling point is the event schema, not a direct synchronous call to another service’s API.

Event-driven microservices aren’t just a deployment strategy. They’re a different way of modeling your business domain. State changes become first-class citizens, and services are genuinely decoupled rather than nominally so.

This is the architecture we’ve invested in, and walking away from it now would mean discarding the very properties that make it powerful.

The Price of Admission

We’re not naive about the tradeoffs. Here’s an honest accounting of what staying on this path requires:

Operational maturity is non-negotiable. You need distributed tracing, structured logging, and health observability. Tooling has matured significantly here: OpenTelemetry, Grafana, and purpose-built messaging infrastructure make this tractable in a way it simply wasn’t five years ago.

Get the boundaries wrong and nothing else matters. The right service decomposition emerges from deep understanding of the business domain. Getting composition wrong is the original sin of microservices: a poorly drawn boundary forces two services to change in lockstep, which eliminates the independence you decomposed to achieve in the first place. Correct composition means each service maps to a genuine capability with a stable interface; one that can evolve, scale, and fail independently. The payoff, when you get it right, is services that rarely need to change together, which is the entire point.

Schema governance is load-bearing. In a system where services communicate entirely through events, the schema is the ultimate contract between producers and consumers. Implementing robust schema registries, enforcing strict versioning strategies, and adhering to backward-compatibility disciplines are not optional overhead; they are structural requirements. Breaking a schema means silently breaking downstream consumers, an operational failure far worse than a compile-time error.

Idempotency must be a first-class citizen. Because high-throughput, distributed event streams inherently rely on at-least-once delivery guarantees, messages will be delivered more than once during network partitions, retries, or rebalances. Every consumer must be designed to handle duplicate events gracefully. Without this foundational discipline, transient network hiccups will inevitably manifest as silent data corruption bugs in production.

Service boundaries enforce structural quality. When a microservice is genuinely independent, the quality bar for that single deployment unit rises. You can no longer paper over poorly isolated boundaries with end-to-end integration tests that accidentally span multiple domains. This architecture forces engineering teams toward contract testing and isolated test suites; practices that surface architectural friction early, exactly where engineering flaws love to hide.

Distributed systems demand a different testing vocabulary. Unit tests and end-to-end tests alone aren’t enough. Chaos engineering (deliberately injecting failures, partitions, and latency into a running system) is the only way to verify that partial failures degrade gracefully rather than cascade. Endurance testing matters just as much: a service that handles load correctly for five minutes but leaks memory or exhausts connection pools over hours will fail in production in ways that no short-lived test suite will catch. These disciplines are expensive to build but more expensive to skip, and they’re largely absent from the testing culture that forms around monolithic codebases.

What This Means for Customers

Architectural elegance means nothing if it doesn’t translate to a reliable experience for the end user. When we committed to event-driven microservices, a significant part of that decision was about what it would mean for the workloads running on top of the platform.

The practical consequences are worth being specific about.

Scalability in a microservices architecture is granular. Individual services scale independently, so a spike in one capability doesn’t force you to scale everything. That matters in an analytics platform where certain workloads are bursty and others are constant. Failover is similarly scoped: redundancy is a property of individual services, not the platform as a whole, which means a degraded component degrades gracefully rather than triggering a cascade.

Because services are independently deployable, fixes and improvements can ship to a specific capability without a platform-wide maintenance window. For teams running our platform in production, that translates to shorter outage windows and lower risk per release. The architecture was designed with operational continuity as a constraint, not an afterthought.

Extensibility follows the same pattern. The REST APIs that our services use to communicate with each other are the same APIs available to third-party developers. There’s no privileged internal interface. That consistency is deliberate: it means the integration model for external tooling is identical to the one for core platform components.

The honest tradeoff is eventual consistency. In a distributed, event-driven system, reads don’t always reflect the latest write immediately. For analytics and data pipeline workloads (which represent the overwhelming majority of what runs on the platform), that’s not just an acceptable tradeoff, it’s the right one. Workloads that prioritize throughput and scale over strict read-after-write semantics are exactly what this architecture was designed to serve.

The Honest Comparison

The monolith advocates aren’t wrong that consolidation can reduce operational complexity for the right team working on the right problem. If you’re a team of 10 building a focused SaaS product with a well-understood domain, a well-structured monolith might genuinely serve you better for the next three years.

But if you’re building infrastructure that must integrate with heterogeneous systems, scale individual capabilities independently, absorb spikes from external event sources, and evolve without coordinated release trains, then you need an architecture that was designed for those constraints.

Microservices with event-driven communication is that architecture. The teams abandoning it, in most cases, are abandoning a poorly executed version of it.

We’re not staying the course out of stubbornness. We’re staying the course because we’ve done the work to execute it correctly, and the results for the customers building on top of it speak for themselves.

Final Thought

The pendulum swings in software architecture because most architectural failures are blamed on the pattern rather than the execution. Microservices didn’t fail those teams. Distributed systems operated without the right tooling, organizational alignment, or domain clarity failed those teams.

We’ve built the tooling. We’ve aligned the teams. We’ve done the domain work.

The exodus is happening around us. We’ll be here when the pendulum swings back.

Have thoughts on event-driven architecture or microservices tradeoffs? Drop a comment below; we’d love to hear from teams on both sides of this debate.

DEV Community: Clint Edwards

Everyone seems to be returning to the monolith, but event-driven microservices are still the right choice for high-scale infrastructure. We’ve built the tooling and aligned our teams. We’ll be here when the pendulum swings back.

The Microservices Exodus: Why We’re Not Leaving

The Microservices Exodus: Why We’re Not Leaving

Everyone seems to be consolidating. Here’s why we’re staying the course on microservices and event-driven architecture.

The Backlash Is Real

What the Backlash Is Actually About

Event-Driven Architecture Changes the Calculus

The Price of Admission

What This Means for Customers

The Honest Comparison

Final Thought