Really solid breakdown of why sync comms become a bottleneck. I've seen production systems tank because teams assumed sync was "simple" until cascading latencies hit. The part about tight temporal coupling is underrated, I think thats where most of the fragility actually comes from in practice. Event-driven architectures do add complexity but theres a point where avoiding them just shifts the complexity onto the infra layer instead.
A lot of engineers equate simplicity with synchronous calls, but at scale, that simplicity becomes hidden coupling and fragility. The emphasis on async, batching, and decoupled flows is a great reminder: designing for latency, failure, and growth upfront is what separates systems that merely work from systems that scale.
Thoughtful piece, and I agree with the core pushback against treating async as a universal default.
Where it feels a bit one-sided is that it frames sync mostly as an anti-pattern, without really acknowledging why synchronous communication keeps reappearing in systems. Some guarantees are fundamentally synchronous by design; REST APIs are a good example. The client and server must agree, in real time, on success, failure, or authority to proceed.
Async shines for decoupling, scale, and resilience, but sync exists because certain interactions require immediate agreement, bounded decision windows, or shared state validation. In practice, most real systems are hybrid, not ideological.
Framing it as “when do we need agreement now vs. eventual coordination later” might land more evenly than sync vs async as opposites.
Really solid breakdown of why sync comms become a bottleneck. I've seen production systems tank because teams assumed sync was "simple" until cascading latencies hit. The part about tight temporal coupling is underrated, I think thats where most of the fragility actually comes from in practice. Event-driven architectures do add complexity but theres a point where avoiding them just shifts the complexity onto the infra layer instead.
Loved the framing of this piece. 👏
A lot of engineers equate simplicity with synchronous calls, but at scale, that simplicity becomes hidden coupling and fragility. The emphasis on async, batching, and decoupled flows is a great reminder: designing for latency, failure, and growth upfront is what separates systems that merely work from systems that scale.
Thoughtful piece, and I agree with the core pushback against treating async as a universal default.
Where it feels a bit one-sided is that it frames sync mostly as an anti-pattern, without really acknowledging why synchronous communication keeps reappearing in systems. Some guarantees are fundamentally synchronous by design; REST APIs are a good example. The client and server must agree, in real time, on success, failure, or authority to proceed.
Async shines for decoupling, scale, and resilience, but sync exists because certain interactions require immediate agreement, bounded decision windows, or shared state validation. In practice, most real systems are hybrid, not ideological.
Framing it as “when do we need agreement now vs. eventual coordination later” might land more evenly than sync vs async as opposites.