CONCEPT Cited by 9 sources

Event-driven architecture¶

Event-driven architecture (EDA) is a software-system style in which services communicate asynchronously by publishing and subscribing to events on a shared bus — not by direct synchronous request/response. Producers don't know which consumers will process an event; consumers control their own queue depth, retention, and processing semantics.

Primitives¶

Event — an immutable record that something happened (OrderPlaced, AccessGranted, DeliveryDispatched). Has a schema, timestamp, and publisher identity.
Event bus — the shared substrate routing events to subscribers. AWS's managed offering is systems/amazon-eventbridge.
Publisher — any service that emits events. Knows the bus, not the consumers.
Subscriber — any service that consumes events matching a filter rule. Decides its own retry / DLQ / processing guarantees.
Routing rule — pattern-based filter matching events to subscribers; in EventBridge the rule language is a content-based JSON pattern.

Why shift to EDA¶

The core failure mode of tightly-coupled synchronous architectures is the cascade: a downstream slowness or outage propagates upstream as timeouts, retries amplify load, and the system deadlocks. Amazon Key's pre-migration architecture explicitly exhibited this — "an issue in Service-A triggered a cascade of failures across many upstream services, with increased timeouts leading to retry attempts and ultimately resulting in service deadlocks". Blast radius was arbitrary: a single-device-vendor issue scoped to one delivery operation caused fleet-wide degradation.

EDA isolates the cascade:

Publisher doesn't wait for the consumer. If the consumer is slow or down, events queue.
Consumer failures don't amplify load on the publisher.
Per-subscriber queue + retry + DLQ policies contain the blast radius to a single consumer.
New consumers are additive: they attach a rule + a target without modifying the publisher.

(Source: sources/2026-02-04-aws-amazon-key-eventbridge-event-driven-architecture)

What EDA costs you¶

Schema governance moves from implicit to explicit. Ad-hoc pub/sub on SNS/SQS without a schema registry produces un-versioned contracts that become impossible to evolve — no place to remove unused fields safely, no way for publishers to detect invalid events before publishing, no audit trail. This is the problem Amazon Key's custom schema repository addresses.
Debugging goes multi-system. No single stack trace across producer → bus → N consumers; observability must correlate events via IDs.
"Exactly once" is not free. Consumers must be idempotent because at-least-once is the default message-delivery guarantee on most managed buses.
Operational surface grows. Per-subscriber IaC scaffolding (dedicated event bus + IAM + monitoring + alerting) can be standardised via reusable-subscriber-constructs to keep this tax bounded.

Seen in¶

sources/2026-09-30-aws-how-mhk-built-a-hipaa-eligible-agentic-ai-solution-on-amazon-bedrock — EDA as the backbone of a controller-agent agentic workflow. MHK's SmartProminence AI Orchestrator makes everything except the Bedrock LLM invocation asynchronous: the orchestration core enqueues a ControllerTaskMessage to start a workflow and AgentTaskMessages to dispatch individual steps onto SQS queues. The post names the four properties this buys — stateless processing (any instance picks up pending messages), independent scaling (agents scale horizontally on ECS Fargate), fault isolation (a failed task doesn't block parallel steps; dead-letter queues capture failures), and decoupled deployment (ship new agent versions with no system-wide restart) — enabling "hundreds of concurrent jobs without resource contention." A clean statement of why an agentic orchestrator is built event-driven rather than as synchronous request/response. (Source: sources/2026-09-30-aws-how-mhk-built-a-hipaa-eligible-agentic-ai-solution-on-amazon-bedrock)
sources/2026-02-04-aws-amazon-key-eventbridge-event-driven-architecture — Amazon Key replaced tightly-coupled synchronous service interactions + ad-hoc SNS/SQS pairs with an EventBridge-centric EDA; reported 2,000 events/s, 99.99% success, 80ms p90 end-to-end latency; five-day → one-day integration time for new use cases.
sources/2025-12-02-github-home-assistant-local-first-maintainer-profile — Home Assistant as a consumer-edge / single-host instance of EDA: every sensor reading, state change, and scheduled check is an event; automations are declarative triggers over the event stream. Distinct from the managed-bus-with- subscribers shape — there is no inter-service bus because there are no services, just one runtime normalising 3,000+ device brands into entities with states + events on a single local host (e.g. Raspberry Pi). Reported scale: 2M+ households. Load-bearing on local-first-architecture.
sources/2026-04-08-aws-build-a-multi-tenant-configuration-system-with-tagged-storage-patterns — EDA applied specifically to the config-refresh problem in patterns/progressive-configuration-rollout: Parameter Store writes emit EventBridge events, a Lambda consumes them and pushes updates to live service instances over gRPC. Escape valve from the TTL-vs-staleness dilemma — changes propagate within seconds without polling or service restarts.
sources/2026-04-23-aws-modernizing-kyc-with-aws-serverless-solutions-and-agentic-ai — EDA applied to agentic-AI orchestration in regulated financial services. MSK carries four inbound topic categories (KYC requests, document uploads, vendor responses, transaction events) and three outbound categories (decisions, escalations, fraud alerts); event listeners pre-process inbound streams. Canonical instance of inbound-outbound-topic-pairing paired with async-agent-invocation-over-kafka — sub-5-minute KYC latency target predicated on the async topic boundary. Distinct from EventBridge instances by using Kafka-API (MSK) because downstream on-prem financial systems already speak Kafka.
sources/2026-08-12-databricks-network-configuration-delivery-to-tens-of-millions-of-serverless-vms — EDA to strip a synchronous multi-service aggregation off a provisioning critical path. Databricks serves network config to tens of millions of serverless VMs/day; the old design synchronously fanned out to all upstream services on every cluster launch (~5,000 ms p99, 99.8% availability from availability multiplication). Upstreams now emit identifier-only change events to a message queue; a background pipeline recomputes and materializes a per-workspace snapshot, and the launch path does a single read (125 ms p99, 99.99%, −86% upstream calls). Canonical instance of event-driven-snapshot-precomputation with a reconciler backstop — EDA used for serving-path pre-computation, not just service decoupling.
— EDA adopted specifically to escape the availability- multiplication ceiling. Zalando Payments's Order Store decouples event publication to Nakadi from the synchronous DynamoDB write using the transactional outbox pattern (realised via DynamoDB Streams + AWS Lambda + SQS DLQ + Kubernetes CronJob). The post opens with the explicit 99.9% × 99.9% = 99.8% arithmetic as the motivation — canonicalised as availability-multiplication-of-dependencies. The accepted trade-off is eventual consistency + at-least-once + out-of-order delivery.
— EDA's durable-source property as the architectural enabler for ingestion-rate control. Zalando's Communication Platform depends on EDA's defining properties — the bus (Nakadi, Kafka- backed) holds un-consumed events durably; subscriptions are pausable — to implement AIMD-driven admission control at the Stream Consumer. The durable bus becomes the overflow buffer during load episodes, so the hot-path broker (RabbitMQ) stays small. Canonical instance of EDA's retention + cursor semantics being load-bearing for admission control, not just for decoupling: "It also helped us to avoid using the RabbitMQ cluster as a storage for millions of messages — with a smaller queue size in RabbitMQ we follow best practices." HTTP-ingress systems lack this property, which is why their load shedding is different (429-plus-retry rather than pause-consumption).

service-coupling — the failure mode EDA addresses.
concepts/schema-registry — the governance primitive EDA forces.
systems/amazon-eventbridge — canonical AWS EDA substrate.
systems/aws-sns, systems/aws-sqs — lower-level pub/sub primitives that, pair-per-integration, become the anti-pattern EDA supersedes at org scale.
single-bus-multi-account — org-scale deployment topology for EDA on AWS.
client-side-schema-validation — the pattern that closes the validation gap in EDA.
s3-event-triggered-composition — S3 event notification as a pipeline-activation trigger in specification-driven composition.

Vehicle-tracking update streams — Bosch L.OS¶

Bosch L.OS uses MSK to turn provider location updates into normalized asynchronous events after consent and trip creation. The split keeps consumer notification off the request/setup path and allows consumers to receive location updates at the selected or provider-supported frequency. Unlike the EventBridge organization-scale examples above, the source describes a Kafka-compatible domain-event bus and does not disclose its ordering, replay, or delivery guarantees. (Source: sources/2026-08-14-aws-serverless-vehicle-tracking-at-scale-bosch-los-on-aws)

Automated security remediation — Cloudflare CASB¶

Cloudflare CASB automatic remediation policies are an EDA pipeline where the "events" are security posture findings. The findings engine detects a misconfiguration → enqueues an orchestration message to a Cloudflare Queue → a consumer Worker evaluates it against policy configuration → matched findings spawn jobs on Cloudflare Workflows. Producer (detection) and consumer (remediation) are fully decoupled, and the webhook action emits a typed event (casb.finding_instance.policy_dispatch) to external SOC/SOAR consumers — a second EDA hop. This is the event-driven substrate under patterns/closed-loop-remediation. (Source: sources/2026-09-11-cloudflare-introducing-automatic-remediation-policies-with-casb)

Merged aliases¶

event-driven-pipeline- event-triggering-orchestration- streaming-first-architecture