An event-sourced application contains all of its information in atomic events. Therefore, the full history and context, how it got into its current state, is available. In order to reproduce the current state for debugging purposes, all events and their individual modifications to the system can be regarded.

The fact that everything that happened to the system is stored atomically has a couple of benefits, not only for debugging purposes.

Tests can make use of this information to replay everything that happened to a production system in system tests. Tests are then able to re-execute the exact business use case invocations that happened in productions. This is an advantage especially for system and performance tests.

The same is true for statistics that use the atomic information to gather insights about the usage of the application. This enables use cases and insights that are designed after an application has been deployed.

Assuming a manager wants to know how many users were created on a Monday, after the application has been running for two years. With CRUD-based systems that information would have had to explicitly been persisted by the time the use case was invoked. Use cases that were not explicitly requested in the past can only be added as new features, and will add value in the future.

With event sourcing these functionalities are possible. Since information about whatever happened to the system is stored, use cases that are developed in the future are able to operate on data that happened in the past.

These benefits, however, are certainly possible without the need for distributed systems. A monolithic, independent application can base its model on event sourcing, gaining the same benefits from it.