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 mortgage applications: 500k submitted/year, 12 steps, autosave every 30s while active, 200k concurrent draft sessions peak, 2 MB avg attachment, 50 KB draft JSON.

Write traffic (autosave)

• Autosave: 200k sessions / 30s ≈ 6,700 PATCH/s peak to draft API.
• Each upsert: 50 KB JSON → 6,700 × 50 KB ≈ 335 MB/s write bandwidth to Postgres (batch or debounce to reduce).
• Final submit: 500k/year ≈ 0.016/s average — negligible vs autosave.

Read traffic

• Resume session: ~same rate as autosave on open ≈ 6,700 reads/s peak for draft fetch.
• Step validation: 6,700 × 12 fields checked server-side — CPU bound, not I/O.

Storage

• Draft JSON: 200k active × 50 KB ≈ 10 GB hot; completed 500k × 50 KB ≈ 25 GB/year retained.
• S3 attachments: 500k × 2 MB ≈ 1 TB/year new blobs — pre-signed PUT, not through API.
• Verification vendor refs: 500k × 200 B ≈ 100 MB metadata.

Network & caching

• Debounce autosave to 60s → halve writes to ~3,350/s — UX trade-off.
• Redis draft lock: 200k × 100 B ≈ 20 MB for optimistic concurrency tokens.
• Webhook inbound: 500k verifications/year ≈ 1/s async — no peak concern.

// Mortgage form autosave storm
const concurrentDrafts = 200_000;
const autosaveIntervalSec = 30;
const peakAutosaveQps = concurrentDrafts / autosaveIntervalSec;
const writeMbps = (peakAutosaveQps * 50 * 1024 * 8) / 1e6; // 50 KB draft
console.log({ peakAutosaveQps: Math.round(peakAutosaveQps), writeMbps: Math.round(writeMbps) });