Unthought.

Event-driven work

A public address carrying somebody else's reliability: verify it, record it, acknowledge fast, do the work afterwards.

An address that accepts events from another company is public infrastructure with somebody else's reliability bolted to it. It will receive replays, forgeries if it declines to check, bursts far above its average rate, and events describing objects the receiving system has never heard of.

Signatures are verified on every inbound request before its contents are trusted for anything. An address that accepts unverified events is an unauthenticated way into the business's systems, published openly, and the fact that the URL is obscure is not a control.

Receipt is acknowledged quickly and the work happens afterwards: check it, record exactly what arrived, return success, and process it separately. A handler performing real work inline will time out under load, the sender reads a timeout as failure and retries, and the retry multiplies exactly the load that caused the timeout. Systems fail this way at the worst possible moment, which is when volume is highest.

Raw payloads are retained as received. When a processing bug is found — and the first version of an event handler is frequently wrong about some field — the remedy is replaying stored events instead of asking a vendor to resend a window they may no longer hold.

Every event is processed so that a repeat is harmless, because replays here are routine rather than exceptional. Vendors resend on ambiguous responses, on their own retries, and occasionally in bulk after an incident on their side.

An event referencing an object the system has never seen is an ordinary case with a defined response, not an exception in a log. The creation may be arriving late, may have been missed entirely, or may concern something outside the scope this business syncs — three different situations that a null-reference error collapses into one unhelpful line.

Outbound notifications the business sends carry the same obligations in reverse: signed so recipients can verify them, retried with backoff, delivery attempts visible to the recipient instead of opaque, and a format that is versioned rather than altered underneath the systems relying on it.

These addresses are treated as sensitive. They are unguessable, kept out of anything a visitor can read and anything public, and replaced if exposed — an address whose only protection is obscurity has no protection, and one with signature verification plus obscurity is simply harder to abuse.

A vendor's sandbox is not a smaller copy of their production system. The shape of what arrives differs, some events are never sent there at all, and rate limits are frequently more generous — so the differences that matter are found deliberately instead of at launch.

Exclusions

What this does not cover.

  • Addresses that process events without verifying their signature.
  • Handlers doing substantial work inline before acknowledging receipt.
  • Outbound format changes shipped without a version, underneath the systems already relying on them.