Lesson 3 of 6
Topics, queues and subscriptions
10 min
Listen to this lesson
A broker is only as manageable as its topics and queues. Topics are where events are published; queues are where they wait for a consumer; subscriptions connect the two. Good design makes routing, security, replay and testing easy. Poor design leaks test events into production queues and makes it impossible to say who receives what.
Topic hierarchies
Topics are strings of levels separated by forward slashes. SAP's standard events arrive on topics derived from the event type, for example sap/s4/beh/salesorder/v1/SalesOrder/Changed/v1, usually behind a namespace prefix for the publishing system. For Contoso's own events, Theo set a hierarchy that puts the most useful filter levels first:
| Level | Meaning | Contoso values |
|---|---|---|
| 1 | Company prefix | cmc |
| 2 | Domain | o2c, p2p, mfg, fin |
| 3 | Business object | coreagreement, fleetorder |
| 4 | Event (verb) | Created, Closed |
| 5 | Version | v1 |
| 6 | Company code | 1710, 1910 |
| 7 | Key (optional) | Agreement or order number, for routing and replay granularity |
Contoso's custom topic hierarchy (illustrative). Example: cmc/o2c/coreagreement/Closed/v1/1710/100045.
Putting company code before the key means a Monterrey consumer can subscribe to cmc/o2c/coreagreement/*/v1/1910/> and never see US agreements. Putting the version in the topic means a v2 consumer and a v1 consumer can coexist. Putting the key last means advanced event mesh replay or routing can be scoped to a single object where needed.
Wildcards
| Wildcard | Meaning | Example | Matches |
|---|---|---|---|
* | Exactly one level, when it stands alone at that level | cmc/o2c/coreagreement/*/v1/1710/> | Created and Closed for 1710 |
> | One or more levels, only at the last level | cmc/o2c/> | Every order-to-cash event |
Wildcards in topic subscriptions, as documented for advanced event mesh. Check the subscription syntax of your broker plan.
Queues
Use one queue per consuming application. Two applications that need the same events get two queues with the same subscriptions; the broker stores and delivers to each independently. Queue settings are part of the design, not defaults to accept:
| Setting | What it controls | Contoso choice for the US refunds queue |
|---|---|---|
| Access type | Exclusive (one active consumer) or non-exclusive (shared among consumers) | Exclusive: the refund logic runs as one instance |
| Partitioned (advanced event mesh) | Shared queue where each key stays on one consumer | Not needed; considered for analytics |
| Maximum redelivery | How often a failing message is redelivered | 5 attempts |
| Dead message queue | Where messages go after redelivery or TTL limits | Separate DMQ per queue, with an alert |
| Time to live | How long a message may wait | Seven days, matching the consumer's deduplication window |
| Quota | Storage the queue may use | Sized for a three-day outage at peak volume |
Queue design decisions for one consumer (names and options vary by broker; check your broker's documentation).
- Does the consumer run as a single instance?Yes → exclusive queue · No → next question
- Must events for the same key be processed in order?Yes → partitioned queue (advanced event mesh), keyed by the business key · No → next question
- Can any instance process any event independently?Yes → non-exclusive queue shared by the instances · No → redesign the consumer before choosing
Walkthrough: adding a consumer
- Elena requests a queue for the warranty app, naming the events and company codes it needs.
- Theo creates
cmc.warranty.agreementsin the test broker with an exclusive access type, maximum redelivery 5, a dedicated DMQ and a TTL of seven days. - He adds the narrowest subscription that serves the need:
cmc/o2c/coreagreement/Closed/v1/>rather thancmc/>. - He grants the warranty app's client credentials access to that queue only.
- Priya's integration test publishes one matching and one non-matching event and checks the queue receives only the first.
- The queue, subscription and owner are added to the landscape page; the same definition is then created in production through the change process.
Naming and housekeeping
Queues outlive projects. Theo's naming rule puts the owner and purpose in the queue name (cmc.warranty.agreements, cmc.fleetnotifier.salesorders), and every queue appears on the landscape page with an owner and a review date. Twice a year the integration team lists queues with no consumer connection for 30 days and asks the owner whether they are still needed. An abandoned queue with a broad subscription keeps filling until it reaches its quota, and in the worst case consumes storage other queues need.
What goes wrong in testing
- Over-broad subscriptions.
cmc/>delivers events the consumer was never tested for. - Shared queues between apps. Two apps compete for messages; each sees only some of them.
- Test events in production queues. Stage namespaces or broker instances are not separated.
- No DMQ. Messages that exceed redelivery are silently discarded.
What would you do?
During testing, the US refunds consumer processes a Monterrey (1910) agreement and creates a refund in the wrong company code. Its queue subscribes to cmc/o2c/coreagreement/Closed/>. What is the best fix?
- Design topic levels so the useful filters (domain, object, event, version, company code) come first and the key last.
- Wildcards: * matches one level; > matches one or more levels and only at the end.
- One queue per consuming application, with explicit access type, redelivery, DMQ, TTL and quota.
- Test subscriptions negatively: prove what must not arrive.
Check your understanding · not graded
Lesson check
1. What does the wildcard > match in a topic subscription?
2. Two apps need the same events. How many queues should they have?
3. Why does Contoso put company code before the key in its topics?
4. What is a dead message queue for?
5. Which test proves a subscription is not too broad?