Event Bus / Pub-Sub
A shared channel where services announce events and any interested subscribers receive their own copy and react independently.
See it
What it is
An event bus or publish-subscribe system lets producers publish facts to a topic without naming the services that receive them. Subscribers register interest and react independently. Amazon SNS, Google Cloud Pub/Sub, and Kafka topics are familiar products built around this separation.
Use pub-sub when a fact such as customer.created or invoice.paid should trigger several workflows and the publisher should not coordinate them. Unlike a single work queue, where workers compete for one message, each subscription gets its own copy; workers inside one subscription may still compete to process that copy.
Decoupled does not mean unspecified. Most managed systems can redeliver a message, and ordering may be limited to a key or not guaranteed at all. Define an event envelope, version schemas compatibly, make subscribers idempotent, and give each subscription retry and dead-letter behavior. Otherwise the bus becomes a place where invisible dependencies pile up.
Ask AI for it
Implement pub-sub with a Google Cloud Pub/Sub topic named customer-events and separate subscriptions for CRM sync, welcome email, and analytics. Publish JSON envelopes containing eventId, eventType, schemaVersion, occurredAt, and data; validate them against a versioned JSON Schema in every subscriber. Configure exponential retry and a dead letter topic per subscription, make handlers idempotent by eventId, and record subscription backlog age and dead-letter count in Cloud Monitoring.