Contrast sync vs async failure classes using first principles

Source: Dev.to

1. Start from First Principles: What Is a “Failure Class”?

A failure class is not:

• a bug
• a timeout
• an outage

A failure class is:

A category of things that can go wrong because of how responsibility, time, and state are structured

So we ask:

• What must be true for correctness?
• What assumptions does the model silently make?
• What breaks when those assumptions are false?

2. Core Difference (One Sentence)

• Synchronous systems fail by blocking and cascading.
• Asynchronous systems fail by duplication, reordering, and invisibility.

Everything else is a consequence.

3. Synchronous Systems — Failure Classes

Definition (First Principles)

A synchronous system assumes:

“The caller waits while the callee finishes the work.”

This couples time, availability, and correctness.

Failure Class 1: Blocking Amplification

Question: What happens while the system waits?

Reality:

• Threads blocked
• Connections held
• Memory retained

Failure mode: Load ↑ → latency ↑ → throughput collapses.
This is non‑linear failure, not just “slow.”

Failure Class 2: Cascading Failure

Question: What if a dependency slows down?

Because everything is waiting:

• Agent slows → backend slows
• Backend slows → frontend retries
• Retries amplify load

Failure mode: One slow dependency can take down the entire system.

Failure Class 3: Availability Coupling

Question: Can the system function if the dependency is down?

Answer (sync): No.

Failure mode: Partial outage becomes total outage.

Summary: Sync Failure Classes

4. Asynchronous Systems — Failure Classes

Definition (First Principles)

An async system assumes:

“Work can finish later, possibly multiple times, possibly out of order.”

This decouples time but removes guarantees.

Failure Class 1: Duplicate Execution

Question: What happens if work is retried?

Reality:

• At‑least‑once delivery
• Worker crashes
• Message reprocessed

Failure mode: Same logical action happens multiple times, breaking exactly‑once semantics and idempotency assumptions.

Failure Class 2: Ordering Violations

Question: What defines sequence?

Reality:

• Queues don’t know business order
• Workers process independently

Failure mode: Effects appear out of logical order.
Example (chat systems): Responses based on future messages → context corruption.

Failure Class 3: Completion Invisibility

Question: How does the user know when work is done?

Reality:

• No direct signal
• Polling or guessing

Failure mode: Users wait blindly or see stale state.

Failure Class 4: Orphaned Work

Question: What if the user disappears?

Reality:

• Job keeps running
• Response stored but never consumed

Failure mode: Wasted compute, leaked state.

Summary: Async Failure Classes

5. Side‑by‑Side Contrast (Mental Model)

6. Deep Insight (Interview Gold)

• Synchronous systems fail loudly and immediately (timeouts, errors).
• Asynchronous systems fail quietly and later (double writes, wrong order).

7. Why Neither Is “Better”

From first principles:

• Sync systems protect causality but sacrifice availability.
• Async systems protect availability but sacrifice causality.

Real systems re‑introduce the lost property:

• Async systems add idempotency, ordering, state machines.
• Sync systems add timeouts, circuit breakers, fallbacks.

8. One‑Line Rule to Remember

• Sync breaks under load.
• Async breaks under ambiguity.

Next steps:

• Map these failure classes to real outages.
• Show how streaming combines both failure types.
• Practice identifying failure classes on a fresh system.