Skip to content

PATTERN Cited by 1 source

Per-surface configuration model

Pattern

Build an event processing platform around well-defined interfaces (for matching, delivery, retry policy, failure handling), and let each event surface supply its own implementation. The core pipeline knows nothing about surface-specific semantics. Adding a new event surface is a self-contained change — declare destination lookup, routing, retention semantics, filtering, and failure behaviour against the shared interfaces, with no invasive change to the core.

Problem it solves

A service handling multiple event types (product events, lifecycle events, repository hooks, audit-log events, workflow events) easily becomes a tangle of if (eventType == X) branches. Over time, each branch accumulates subtle differences in retry budget, timeout, ordering, and failure semantics — but they all run in the same code path, creating coupling that makes each surface change risky.

Benefits

  • New surfaces don't ship with a minimum-viable webhook — they inherit the same delivery discipline, observability, and fairness the rail was built for.
  • Operational isolation — each surface's retry policy, timeout budget, and failure-recovery shape is declared, not emergent.
  • Reduced risk of silent failures — mixing surfaces with different semantics into a single undifferentiated queue or codepath is "one of the cleanest ways to create silent failures."

Seen in

Last updated · 602 distilled / 1,824 read