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.

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 #backend

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.

C++ Didn’t Get Slower — Go Got Better

Clint Edwards — Fri, 24 Apr 2026 14:22:04 +0000

What a side‑by‑side gRPC benchmark reveals about modern concurrency, scheduling, and the real cost of performance

C++ didn’t lose its edge. It didn’t suddenly become slow, unsafe, or obsolete.

What changed is that languages like Go — and increasingly Rust — got good enough that raw performance differences are often small , while the cost of building, operating, and maintaining equivalent systems in C++ remains high.

That shift matters more than most benchmarks suggest.

We benchmarked the same production gRPC proxy written twice: once in Go, once in C++. The results don’t show a clear performance winner — they show why runtime design, tail latency, and engineering economics now drive the decision more than peak throughput ever did.

The experiment

We recently open sourced Arke — a production gRPC proxy for message brokers written in Go.

The predictable response was:

“Sure, but how much faster would this be in C++?”

So we answered it directly.

We ported arke to C++, kept the .proto files identical, and ran both implementations through the same benchmark harness. No synthetic loops, no micro‑benchmarks — just real gRPC clients exercising real concurrency and I/O.

What arke does (briefly)

Arke sits between your application and a message broker (RabbitMQ, etc.) and exposes a uniform gRPC API regardless of backend.

It provides three services:

Producer — Connect, PublishOne, Publish (bidi), Disconnect

Consumer — Connect, Consume (bidi), SourceStats, Disconnect

Healthz — Check (bidi heartbeat)

The differences are strictly runtime and ecosystem:

Go: amqp091-go, goroutines, zerolog
C++: librabbitmq, std::thread, spdlog

Both use the same generated gRPC interfaces.

Benchmark setup (short version)

Apple M1 Pro, localhost RabbitMQ
grpc‑go vs grpc‑cpp
Warm‑up runs, real clients
Throughput plus p50 / p95 / p99 / p99.9 latency recorded

The goal wasn’t micro‑performance. It was understanding behavior under load.

Scenario 1 — Connection‑heavy paths

Producer.Connect is called on existing connections, and negotiates AMQP sessions with the broker.

What happened

At low concurrency , Go and C++ performed similarly.
At moderate concurrency , results fluctuated.
At higher concurrency , Go consistently showed better tail latency.

At 10 workers (p99.9 latency):

Go: ~1.4 ms
C++: ~3.5 ms

With raw throughput so similar, the focus is on tail behavior. Goroutines park cooperatively. std::threads block in the kernel. Under burst load, that difference matters.

Scenario 2 — Steady‑state publishing

Producer.PublishOne represents the typical case: established connections publishing messages as fast as possible.

What happened

C++ had a slight edge at very low concurrency.
At ~10 workers, both saturated RabbitMQ at ~16K requests/sec.
Beyond that point, scheduling effects dominated.

Key point:

Once the broker becomes the bottleneck, language choice largely disappears from the equation.

The saturation point is a product of the runtime environment.

Scenario 3 — Pure gRPC overhead

Healthz.Check removes the broker entirely, isolating the runtime.

What happened

At very low concurrency, C++ was faster.
At moderate and high concurrency, Go pulled clearly ahead on tail latency.

At 10 workers (p99.9 latency):

Go: ~5.8 ms
C++: ~14.6 ms

This gap exists with no I/O, minimal allocation pressure, and no GC involvement. It comes directly from scheduling and blocking behavior.

How big is the performance difference?

Smaller than it appears in isolation.

Across the benchmarks, throughput numbers were often close, peak rates frequently aligned, and measured differences commonly fell within single‑digit percentages. In many cases, both implementations reached similar limits despite very different runtime designs.

Which leads to the more consequential point.

**The cost that does differ significantly**

Performance gaps have narrowed, but C++ development and maintenance costs have not. Extracting marginal gains typically requires more complex concurrency, stricter lifetime management, and ongoing vigilance against subtle correctness issues. These costs don’t appear in benchmarks, but they compound over time — and when performance gains are small, they dominate the trade‑off.

What this actually shows

This benchmark isn’t saying “Go is faster than C++.”

It shows something more important:

C++ excels when absolute control matters
Go excels when concurrency and tail‑latency behavior dominate
Rust targets a similar space, trading simplicity for stronger safety guarantees

Modern systems fail less often because of raw speed, and more often because of scheduling pathologies, queue buildup, and unpredictable tails.

That’s where Go — and increasingly Rust — change the equation.

Should you rewrite a C++ system?

Maybe — if the gains justify the cost.

In most systems, the performance difference is small. Throughput converges, saturation points align, and wins are often negligible.

The development and maintenance cost is not.

If C++’s added complexity isn’t buying you meaningful gains in latency, reliability, or capacity, then Go or Rust can deliver near‑equivalent performance at a much lower long‑term cost.

The takeaway

The modern trade‑off isn’t speed versus safety.

It’s marginal performance gains versus ongoing engineering cost.

C++ still defines the floor — but Go and Rust are reshaping the ceiling.