4 ms·
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 h
by LargeWu 7y ago
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.
- rmetzler 7y agoI just wonder, when you have a queueing system, can’t you use this for distributed logging?
- iddqd 7y agoImagine 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.
- rswail 7y ago> 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.