Introduction to Event-Driven Architectures with RabbitMQ

Re:Introduction to Event-Driven Architectures with RabbitMQ by LargeWu on Thursday August 29, 2019 @11:13AM (#20830202)

It can be very hard to know the state of a piece of information within your system unless you fanatically log its state at all times. And even then, you might have to look through lots of distributed logs to find that. Of course, logging the state of the world at every step also creates tons of noise.

At a previous gig, we had a processing workflow where an entity might move through any of 20 processes tied together through queues. It was very, very difficult to track down problems with things dropping out, things getting stuck, etc.

[ Parent | on HN ]

Re:Introduction to Event-Driven Architectures with RabbitMQ by rswail on Friday August 30, 2019 @02:43AM (#20836408)

> where an entity might move through any of 20 processes

To me that's a design smell. The processes should be making requests of the entity via messaging. Each process should result in the entity emitting a change of state. That change of state should be the trigger for subsequent processes.

[ Parent | on HN ]

Re:Introduction to Event-Driven Architectures with RabbitMQ by rmetzler on Thursday August 29, 2019 @12:04PM (#20830699)

I just wonder, when you have a queueing system, can’t you use this for distributed logging?

[ Parent | on HN ]

Re:Introduction to Event-Driven Architectures with RabbitMQ by iddqd on Thursday August 29, 2019 @12:23PM (#20830922)

Imagine if you flipped on debug logging and suddenly your queueing system gets DDoS by log messages, causing more errors and cascading effects, taking down your product. It’s always a good idea to separate the two.

[ Parent | on HN ]