Literally one log - which does indeed reduce your coordination headache, but is susceptible to your "giant ass mutex" comment, and
One log per ... - which brings the coordination problems right back into existence.
- We mean using one log across different concerns like state a, communication with b, lock c. Often that is in the scope of a single entity (payment, user, session, etc.) and thus the scope for the one log is still small, and it reduces coordination headache for coordinating between the systems. You would have a lot of independent logs still, for separate payments.
- It does _not_ mean that one should share the same log (and partition) for all the entities in your app, like necessarily funneling all users, payments, etc. through the same log. What would be needed if you try and do some multi-key-distributed transaction processing. That goes actually beyond the proposal here, and has some benefits of its own, but have a hard time scaling.
This does not follow.
Neither the dev (nor the product seller) is in control of what real-world effects have a causal relationship.
If my actions can be independently processed from your actions, then we don't need to coordinate, and micrologs will perform faster than a monolog.
If my actions cannot be independently processed from your actions, then we do need to coordinate, unless we use a monolog, which kills performance.
Either way, we don't get to choose the level of independence. If the actions are dependent, we either coordinate or or mess up causality.