Skip to content
Developer Failure Diagrams

Three-scenario free sample · Original assets

Explain the failure.
Show the boundary.

Ready-to-use webhook and data-review illustrations. Choose a theme, inspect the assumptions, then adapt the source to your own document.

Native SVG text · No external fonts · Editable JSON · Built by Shruti

Read the caption library

Scenario 01

One event. Two deliveries.

An event receipt saved separately from a local mutation leaves a crash window. A unique event-ID receipt and the mutation can commit together; a replay can then skip a committed receipt.

Failure: event, mutation, crash before receipt, repeated mutation. Alternative: verify event, begin transaction, unique receipt with local mutation, commit and skip repeats.
Select the image to inspect native SVG text at full size. Light SVG · Dark SVG
Assumptions and accessible description
  • Use a database-enforced unique event key; concurrent deliveries cannot both insert it.
  • Rollback both the receipt and mutation if the transaction fails. A committed receipt, not an in-memory flag, gates replays.
  • Distinct event IDs can represent the same business action. Define additional business keys when needed.
  • This does not make email, remote API calls or every downstream effect exactly once.

Alt description: Failure: event, mutation, crash before receipt, repeated mutation. Alternative: verify event, begin transaction, unique receipt with local mutation, commit and skip repeats.

Technical reference: Stripe webhook documentation. Original artwork; no affiliation.

Scenario 03

Acknowledge after durable handoff.

Returning success before a durable handoff can lose work if the process crashes. Keep reception short, acknowledge only after accepted storage, and let a separate worker retry the retained item.

Failure: verify event, acknowledge, lose in-memory work in a crash. Alternative: verify, durably store work, acknowledge acceptance and retry from storage.
Select the image to inspect native SVG text at full size. Light SVG · Dark SVG
Assumptions and accessible description
  • Use a durable queue or database, not a promise, process memory or an uncommitted write.
  • Provider timeouts and retry windows must be checked. An uncertain enqueue result can yield duplicates.
  • The worker needs its own deduplication, retry limits, failure visibility and side-effect policy.
  • Persist only approved payload data with suitable retention; this drawing is not a security checklist.

Alt description: Failure: verify event, acknowledge, lose in-memory work in a crash. Alternative: verify, durably store work, acknowledge acceptance and retry from storage.

Technical reference: Stripe webhook documentation. Original artwork; no affiliation.

Scenario 06

A line break is not always a row.

A quoted CSV field can include a line break. The included tiny fixture has three physical lines but only a header and one data record. A line-based split is not a CSV parser.

Failure: split a quoted CRLF into two rows and report a false mismatch. Alternative: choose dialect, parse quoting, retain the embedded break and validate actual records.
Select the image to inspect native SVG text at full size. Light SVG · Dark SVG
Assumptions and accessible description
  • Fixture bytes use CRLF, comma delimiter and double-quote enclosure. No trailing record newline is added.
  • Header is a parsed record but not a data row: two records here, one data row.
  • Other CSV dialects and encoding policies need explicit decisions; RFC 4180 is informational guidance.
  • Parsing does not certify business validity, safe spreadsheet execution or migration correctness.

Alt description: Failure: split a quoted CRLF into two rows and report a false mismatch. Alternative: choose dialect, parse quoting, retain the embedded break and validate actual records.

Technical reference: RFC 4180. Original artwork; no affiliation.