Pub/Sub
Global pub/sub messaging with at-least-once delivery.
Problem it solves: Many consumers need the same events, in order per key, with replay.
Where it sits: Producers append; consumer groups read at their own offsets.
When to use
- Event-driven architectures, analytics pipelines, CDC.
When not to use
- Simple task queues with per-message acks.
Failure modes
- Hot partition limits throughput.
- Consumer lag grows during rebalances.
Metrics to watch
- Consumer lag per partition
- Bytes in/out
- Under-replicated partitions
Alternatives
- Message queue
Configuration in Labs (illustrative defaults)
- Queue capacity (messages) = 100000000 — Messages the queue can hold. Beyond this, new messages are rejected (dropped).
- Base service time (ms) = 5 — Processing time per request at zero load. Queueing adds to this as utilisation rises.
Vendor examples (pattern only): Google Cloud managed service. Simulated as a generic “Event stream / topic”.