[sewen]

I can see where some of that could be written more clearly. To elaborate:

- 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.

[mrkeen]

> thus the scope for the one log is still small, and it reduces coordination headache for coordinating between the systems.

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.