3

which set up would you implement:

  • a queue per destionation
  • a queue per message type

Some informations to my set-up:

  • Producers are Macro-Services (they produce messages (different tyoes) to a fanout exchange)
  • Consumers are also Macro-Services (Java App or ETL-App) and take care of binding / routing
  • a producer and a consumer have actually up to 3 APIs (in future the API amount will increase probably have up to 10 APIs (per Poducer x Consumer)
  • please pay attention, that the project has 8 Macroservices, which can be producers and consumers

enter image description here

nusmanov
  • 451
  • 4
  • 15

1 Answers1

1

Job A - Send a email: Consumer is the email service that send a email to target

Job B - write to DB: Consumer B update data from given model

when everything works, as usual is cool.

Chaos scenario: mail service error (whatever reason)

  • a queue per destination (FIFO): email service error, message stuck on the queue, you can't update your DB because email messages are stuck

solution dead letter queue, stuck after x retry move to dead queue. previous messages will go on

  • a queue per message type: email service error, message for emails are stuck, DB is updating as usual only emails are failing

think the work case to help you take most resilience choice

yes, "a queue per destination", less code, easier to scale workers ... but in case of problem.... this solution will be done quickly (but start with dead letter queue) (infra as code, less to do)

"a queue per message type" will reduce the failure "a queue per message type" require more work at the beginning but will reduce maintenance/manual work over time and the code base will be easier to understand for next devs (infra as code, more to do)

To finish think error case

J-Jacques M
  • 978
  • 6
  • 16