A developer on DEV Community breaks down system failures using first principles, arguing that a failure class isn't a simple bug or timeout. Instead, it's a category of problems arising from how responsibility, time, and state are structured. The core distinction is stark: synchronous systems fail through blocking and cascading effects, while asynchronous systems fail through duplication, reordering, and invisibility.

In synchronous architectures, the caller waits for the callee, coupling time and availability. This creates a non-linear failure mode where increased load drives latency up and throughput collapses. A single slow dependency can trigger a cascading failure, taking down the entire system.

Because availability is transitive, a partial outage inevitably becomes a total one. Conversely, asynchronous systems decouple time but remove guarantees. They suffer from duplicate execution due to retries, ordering violations from independent workers, and completion invisibility where users wait blindly.

Orphaned work also wastes compute. The author notes that synchronous systems fail loudly and immediately, whereas asynchronous ones fail quietly and later. Ultimately, neither is superior; sync protects causality at the expense of availability, while async does the opposite.

Real-world systems simply attempt to reintroduce the lost property.