Want to learn the difference between event sourcing and audit logs? In this article we explain what audit logs and event sourcing are, the key differences and which is best for auditing and compliance.
Audit logs are records of events or transactions that occur within a software system.
They provide a detailed history of changes made to the system, including who made the changes, when they were made, and what was changed.
There's nothing prescriptive about what should be in an audit log item, and this is where it usually becomes leaky because proving full fidelity is only something that can be done through event sourcing (more on this below).
In software development, audit logs play a critical role in ensuring the quality, security, reliability of software applications, and complying with regulatory requirements.
Audit logs typically record high-level activities or transactions and tend to only record the end result or significant state changes.
They are append-only logs meaning that events are added and not overwritten. Events entered into the log include other information such as timestamps, user information, action descriptions and results.
Audit logs are mainly used for auditing and compliance and are useful for tracing the history of changes and identifying unauthorized or suspicious activity.
Although event sourcing is similar to audit logs and can be used for auditing, it does differ.
Event sourcing is a persistence pattern that captures all state changes in a sequence of events in an append-only log.
Unlike an audit log that only records the end result, event sourcing captures every change and is focused on maintaining a complete history of all changes that occur in a system or domain.
Every change is captured as a discrete event at a more granular level. Each event typically includes the details of the event itself (the what), the name of the event (the why) and the timestamp of the event (the when).
By capturing every change in a sequential order in an append-only log, events can be replayed to any point in time to provide a full history of what occurred along with detailed context – which is ideal for auditing.
Event Sourcing is not just ideal for auditing, but allows better system testing, debugging, and recovery by allowing the system to be rolled back to a previous state or replayed from scratch.
Want to learn more about event sourcing? Download our Beginners Guide to Event Sourcing.
One of the key differences between event sourcing and an audit log is how events are captured.
A useful analogy is that events in an audit log are like events written down in history books. It’s mostly accurate, but it’s an account of what has happened. Which sometimes can be up to the imagination of the author.
Whereas, events captured by event sourcing are the irrefutable events themselves. It is the absolute fact and there's no room for interpretation.
In event sourcing, events capture the change itself that occurred in the system and are evaluated to make the next decision. In addition, the correctness of the events and completeness of the log must be strictly enforced because a business’ day to day operation depends on.
An audit log is just an account of the change that occurred. The events are recorded in a log, and have no effect on the application state, and hence is not used to make decisions or changes in an application.
This also creates another potential issue with audit logs and that’s identifying and fixing bugs. Because audit logs aren’t used for business operations and are mostly only for regulatory purposes, bugs are often discovered just before an audit.
For example, credit card transactions are audited to deter fraudulent activities. When these transactions are recorded with event sourcing, mistakes can be spotted quickly because whether the next transaction is accepted or declined depends on previous transactions and whether it has exceeded the credit limit. Customers and merchants would be quick to spot problems when a transaction is unexpectedly declined.
Credit card statements will also be heavily reliant on the events because its balance will be wrong if the events don’t add up. For observant customers this will be easy to spot and raised as an issue!
Recording transactions with an audit log on the other hand is only tested by the development team and inaccurate events have much less of an impact compared to risk of problems with daily operations.
In other words, event sourcing focuses attention on ensuring a bug free system as bugs are more likely to be spotted.
The other advantage of using event sourcing is that the audit log is ‘in-built’ due to the immutable storing of events in the append-only log.
The table below shows the key differences between audit logs and event sourcing:
| Feature | Event Sourcing | Audit Log |
| Purpose | Maintain a complete history of state changes in the application | Track user actions and system changes for security and compliance |
| Granularity | Very granular, capturing every state change | Typically high-level, capturing significant actions or transactions |
| Structure | Append-only log of immutable events | Append-only log of action records |
| Events Recorded | Each event represents the fact that occurred, so are more reliable | Events recorded in an audit log are only an account of the action performed. While these are accurate they are often less reliable |
| Reconstruction | Can reconstruct system state by replaying events | Not designed for reconstructing system state |
| Usage | Core part of system architecture for state management | Used for monitoring, auditing, and compliance reporting |
| Typical Contents | Event identifier, timestamp, details of state change | Timestamps, user info, action descriptions, results |
| Focus | Ensuring complete historical state accuracy | Ensuring security and compliance |
| Immutability | Events are immutable and never changed | Entries are not typically immutable and append-only |
| Querying | Often requires event replay to get current state | Direct querying for audit purposes |
| System Recovery | Facilitates rollback and recovery by replaying events | Primarily for investigation and compliance, not for recovery |
| Complexity | Higher complexity, requires careful design | Generally simpler, added as an auxiliary feature |
While both approaches capture and store changes that occur in a domain, which approach you choose depends on your specific use case.
Audit logs are ideal for when you need to track user actions, meet compliance requirements, monitor security, and debug issues. They are straightforward to implement and serve as an excellent tool for monitoring and post-mortem analysis.
Event sourcing on the other hand is best suited to more complex use cases, for example, when you need to ensure the consistency and integrity of your system’s state, want to reconstruct state from a series of events, or need advanced querying capabilities over the historical state.
This is particularly relevant for complex domains where state reconstruction and temporal analysis are critical.
Audit logs and event sourcing both record changes to a system’s state by recording events in an append-only log. Both are suitable for auditing and compliance.
Which approach you choose is down to your own, individual use case and the complexity of your domain. However, event sourcing not only provides an ‘in-built’ audit log, but a more robust approach to auditing and compliance that’s based on capturing the facts of business operations.