Back-of-the-Envelope Estimation

Order-of-magnitude checks catch designs that cannot work. Adjust assumptions for your interview scope — exact numbers matter less than which component becomes the bottleneck.

Assume e-commerce: 2M orders/day, 5 saga steps each, 20% failure requiring compensation, 10% of orders wait 24h on KYC step, workflow history 2 KB per step.

Workflow throughput

• Orders: 2M/day ≈ 23/s average, peak (Black Friday ×20) ≈ 460 new sagas/s.
• Steps: 460 × 5 ≈ 2,300 activity invocations/s peak — each idempotent HTTP call to inventory/payment/ship.
• Compensations: 20% × 460 ≈ 92 reverse flows/s on failure spikes.

Storage

• Workflow history: 2M orders × 5 steps × 2 KB ≈ 20 GB/day ≈ 7 TB/year — Temporal/Step Functions persist full event log.
• Sleeping workflows (KYC 24h): 200k in-flight × 2 KB ≈ 400 MB state — durable timers, not blocked threads.

Messaging & network

• Kafka choreography (optional): 2M × 3 events × 500 B ≈ 3 GB/day async side effects.
• Orchestrator ↔ services: 2,300 RPC/s × 5 KB ≈ 11 MB/s — low bandwidth, latency per step dominates (Stripe ~200ms).

Memory & caching

• Worker memory: replay history on crash — disk-backed in Temporal, not all in RAM.
• Idempotency cache (Redis): 460 new/s × 3600s × 100 B key ≈ 165 MB/hour churn for duplicate detection.

// Black Friday checkout sagas
const ordersPerDay = 2_000_000;
const peakMultiplier = 20;
const stepsPerOrder = 5;
const peakOrdersPerSec = (ordersPerDay / 86_400) * peakMultiplier;
const peakActivitiesPerSec = peakOrdersPerSec * stepsPerOrder;
console.log({ peakSagasPerSec: Math.round(peakOrdersPerSec), peakActivitiesPerSec: Math.round(peakActivitiesPerSec) });