how it works

What is behind Drop

Every box below is a real service doing real work — payments in test mode, files in object storage, email that actually sends. Nothing here is stubbed for the demonstration, because a stubbed dependency cannot fail, and the failures are the point.

The rules Drop is built on

A failure never becomes a plausible success

If the email fails, the order stays complete and the download keeps working — and the dashboard says email failedwith the provider’s own words, not a red dot. If the product file is missing, a valid download link returns an error rather than a zero-byte file the browser cheerfully saves. Silence is the failure mode this whole application argues against.

Inventory cannot go negative

A purchase decrements stock in one guarded atomic update — never a read followed by a write. Two people clicking buy on the last copy is a race the database resolves, not the application.

A replayed webhook cannot double-sell

Orders are idempotent by unique index rather than by checking first. The second insert fails with a duplicate key, which is the correct outcome and is handled as success. Stripe retries webhooks; that is not hypothetical.

Retries are finite, and giving up is visible

A failed delivery retries four times with backoff and then stops — and says it stopped. “Failed” and “failed and nobody is still trying” need different actions from the creator, so they are never the same word.

Watching it

Beaam receives OpenTelemetry from every request and connects to each provider directly, so it can tell the difference between this shop is broken and a dependency is broken. The shop can be broken on purpose to demonstrate that: slow checkout, declined payments, failed email, an uncaught browser exception, or telemetry going silent while traffic carries on.

Source: github.com/teqnyk/drop.