Events remain a useful technical mechanism to transmit state and data among application resources but they are a miserable experience for developers and operators alike. Events:

    - Put application state and data in dozens of queues that make the application prone to failures, race conditions and incorrect results
    - Force developers to think and program asynchronously which is more complex and time consuming than synchronous code
    - Require developers know more than just their portion of the code and application domain: they also need to understand how to work with queues, caches and event schemas
    - Make applications difficult to troubleshoot as there is no one place to understand the state and data for an application

On their own, additional dependencies won't solve problems inherent in the skills/experience/makeup of your team. Open source is great, but projects come and go, and newer ones come with more risk.

---

Side note: the only content on the homepage is a button that says "Skip Overview", which is very funny.

> Put application state and data in dozens of queues that make the application prone to failures, race conditions and incorrect results

In 2025 I literally have no way of verifying if a system is in the correct state other than to hold the events in my left hand, the current state in my right hand, and ask, "do these add up?". Trying anything else is like operating directly on bank balances instead of keeping a list of transactions.

Yes, while two DebitEvents are in flight through the system, different nodes will see varying balances. If they're quick enough, they might even break an invariant you had hoped to maintain (debiting an account below zero). But the nodes (and the programmer) have something to compare to.

[flagged]