Event-Driven Architecture with Anypoint MQ (Course #eda-mq)

Programme every line is something you do

5 modules · 15 topics · in course-flow order

1. Module 1

   Coupling is the design decision

   Objective. Arbitrate the coupling of each Brightgrid integration — Anypoint MQ, JMS or HTTP callback — and emit a decision matrix covering all 7 country feeds.

   • Separate command from event: rewrite 6 request-reply integrations as published facts, naming producer, consumers and retention per feed
   • Score Anypoint MQ, JMS brokers and HTTP callbacks on delivery guarantee, broker ownership and operability, one row per integration
   • Size the envelope against hard ceilings — 10 MB maximum payload, two-week maximum message TTL — and apply claim-check to Object Store v2 beyond them
2. Module 2

   One publish, many consumers

   Objective. Design the queue-and-exchange topology that fans one meter event out to billing, analytics and outage management without a producer change.

   • Draw the topology: point-to-point queues for work distribution, message exchanges for fan-out to 3 independent consumer groups
   • Bind and route deliberately — up to 450 queues per message exchange, but only 25 once intelligent message-routing rules are in play
   • Onboard a fourth consumer with zero producer deployments: bind a new queue, prove the publisher binary is untouched, measure delivery lag
3. Module 3

   At-least-once means duplicates

   Objective. Prove consumer idempotency under forced redelivery, then evaluate what strict FIFO ordering actually costs at Brightgrid's volumes.

   • Build idempotent consumers keyed on meter-id plus reading-timestamp in Object Store v2, proving zero double-billing across 10,000 forced redeliveries
   • Weigh FIFO's exactly-once ordering against its ceilings: 10 in-flight messages per message group and 300 TPS, reaching 3,000 TPS only by batching 10 per operation
   • Partition ordering to where it is genuinely required — one message group per meter, maxConcurrency at 1 — and re-measure against the 18,000 events/second storm peak
4. Module 4

   Acknowledge, or it comes back

   Objective. Construct a tuned Anypoint MQ subscriber — acknowledgement mode, timeout and prefetch — that sustains peak load without triggering redelivery storms.

   • Match acknowledgement mode to blast radius across all 3 modes — AUTO, MANUAL, IMMEDIATE — and price the message loss each one permits
   • Set the acknowledgement timeout from measured processing time, treating 12 hours as the ceiling and not a default, so slow consumers stop reprocessing finished work
   • Tune the subscriber: prefetch buffering versus polling at 10 messages per second, held against the 120,000 in-flight ceiling of a standard queue
5. Module 5

   Poison messages don't disappear

   Objective. Construct the dead-letter and replay path — DLQ policy, triage runbook, redrive flow — and prove a six-hour backlog reprocesses without duplicates.

   • Set a dead-letter queue policy per queue: 10 delivery attempts by default, tunable from 1 to 1000, sized to the downstream's real recovery time
   • Triage before redriving — browse up to 50 messages on a standard queue, 10 on a FIFO queue — and split schema faults from transient faults
   • Build the redrive flow Anypoint MQ does not ship: replay 210 million events inside a 4-hour window with rate control and idempotency keys intact

References & Official Documentation every claim above has a source

Module 1

• Anypoint MQ GlossaryMuleSoft Docs
• Anypoint MQ OverviewMuleSoft Docs

Module 2

• Route Messages by Configuring Rules on Message ExchangesMuleSoft Docs
• Sending Messages to Multiple Queues Using Message ExchangesMuleSoft Docs

Module 3

• FAQ: Anypoint MQMuleSoft Docs

Module 4

• Anypoint MQ ACK and NACK OperationsMuleSoft Docs
• Anypoint MQ Subscriber SourceMuleSoft Docs

Module 5

• Configuring and Using QueuesMuleSoft Docs

More in Architecture