Pub/Sub topic + subscription design
A reference architecture for event-driven systems built on Meridian primitives — topics, subscriptions, dead-letter queues, and push/pull delivery.
Overview
This recipe walks through designing a durable pub/sub topology. You will define a topic, attach subscriptions with filtering, configure retry policies, and wire up dead-letter handling for messages that cannot be delivered.
Topic definition
A topic is a named channel that accepts published messages. Choose a name that reflects the domain event — for example, order.created or invoice.paid. Topics are immutable after creation; plan your naming convention before provisioning.
Subscription model
Each subscription binds a consumer endpoint to a topic. You can attach multiple subscriptions to a single topic, each with its own filter expression, delivery type (push or pull), and acknowledgement deadline. Push subscriptions deliver messages to an HTTPS endpoint; pull subscriptions let the consumer poll for batches.
Retry and dead-letter
Configure exponential backoff with a maximum retry count. Messages that exceed the retry limit are routed to a dead-letter topic for inspection. Attach a separate subscription to the dead-letter topic so your operations team can replay or discard poisoned messages without blocking the main pipeline.
Next steps
Once your topology is provisioned, instrument delivery latency and backlog depth. Set alerts on dead-letter queue growth. For multi-region deployments, replicate topics across Meridian clusters and use regional subscriptions to keep latency low.