Skip to content

PATTERN Cited by 1 source

Reusable subscriber constructs

Package subscriber-side infrastructure for an event-driven system as a versioned IaC construct library so consuming teams provision their subscriber stack from a few lines of code. The construct encapsulates the dedicated subscriber event bus, cross-account IAM, standardized monitoring + alerting — the cross-cutting pieces every subscriber needs but nobody should hand-build N times.

Shape

A subscriber construct invocation looks like (Amazon Key's, roughly):

const subscription = new Subscription(scope, id, {
    name: "DeliveryService",
    application: {
        region: Region.US_EAST_1,
    },
});

...and from those ~5 lines, the construct creates:

  • A dedicated event bus in the subscriber's account (not shared — each subscriber gets its own to isolate retention / DLQ / failure policies).
  • Cross-account IAM roles + policies authorizing the central event bus (patterns/single-bus-multi-account) to deliver events to this subscriber.
  • Standardized monitoring — CloudWatch metrics for event delivery, subscriber processing latency, DLQ depth.
  • Standardized alerting — alarms wired to the service team's on-call channel per platform convention.
  • Optionally: wiring to the shared client library for deserialization.

Why build a construct library

  • Configuration drift is eliminated at the infrastructure layer. Just as patterns/client-side-schema-validation closes the integration-error class at the developer layer, reusable constructs close the same class at the infra layer — every subscriber is provisioned the same way by definition.
  • Architectural patterns become unspoken. Teams don't have to remember to configure DLQs, cross-account roles, or monitoring — the construct does it.
  • Platform team governance surface. Changes to monitoring conventions, IAM baseline, or default alarm thresholds ship as a library version bump, not a campaign to update N Terraform modules.
  • Cognitive cost for subscribers drops toward zero. Subscriber teams focus on processing logic, not infrastructure setup.

Required capabilities

  • IaC framework with first-class reusable-component abstraction. AWS CDK Constructs are the canonical AWS realization; Terraform modules / Pulumi components are analogues.
  • Cross-account permission story. Must express cross-account IAM
  • bus resource policies cleanly.
  • Versioned, semver-disciplined release process for the library so breaking changes don't surprise consumers.

Tradeoffs

  • Library-maintenance burden. The platform team now owns a public-facing API; every minor bump requires compatibility review.
  • Escape hatches required. Some subscribers will have legitimate non-default needs (retention, cross-region, extra targets); the construct must allow override without forking ("golden path with escapes" — see patterns/golden-path-with-escapes).
  • Version-skew complexity. Different subscribers pinned to different construct versions. Not worse than Terraform modules, but not automatically solved either.
  • Stops short of the publisher side. This pattern addresses subscribers; publishers are served by patterns/client-side-schema-validation on the event-publishing path.

Why subscriber, specifically?

Publishers have one concern (make an event and put it on the bus) — handled by the client library. Subscribers have a fleet of concerns:

  • Cross-account authorization to receive from the central bus.
  • Per-subscriber bus / queue (so one slow subscriber doesn't back up others).
  • DLQ + retry + alarm plumbing.
  • Event-target wiring (Lambda / SQS / Step Functions / ECS task / ...).
  • Monitoring and SLA ownership.

That fleet is exactly what an IaC construct library is good for — composite infrastructure with opinionated defaults + explicit override surface.

Seen in

  • sources/2026-02-04-aws-amazon-key-eventbridge-event-driven-architecture — Amazon Key's CDK subscriber constructs library automates the dedicated event bus + cross-account IAM + monitoring + alerting provisioning for every downstream service subscribing to the shared EventBridge bus. Subscribers integrate in ~5 lines of CDK; the library enforces consistent implementation of the organisation's architectural patterns. Reported publisher/subscriber integration time 40h → 8h.
Last updated · 200 distilled / 1,178 read