| div | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
|
Overview
| Excerpt |
|---|
Of Talon's two |
High Availability models, Event Sourcing requires more discipline to use, but can yield better performance particularly for latency sensitive applications. In event sourcing replication of application state to a backup is done by replicating only the |
application's inbound messaging stream. The idea is that by replaying the exact same sequence of events through the same application business logic, the application will produce the same changes to state and produce the same set of outbound messages. |
This section discusses the anatomy of an application coded for Event Sourcing. |
- Received messages don't require re-serialization before replication (they are received in serialized form)
- Received messages can be replicated in parallel with execution of business logic which can effectively reduce the storage cost to 0.
While this the premise behind Event Sourcing is simple, it requires discipline on the part of the application developer to ensure that no business logic decisions are made based on any data but that in the inbound messages and the state generated by those message to date, otherwise it would lead to divergent state on the primary and backup members. For example, something as simple as making a logical decision based on System.currentTimeMillis() could lead to the primary instance accepting an order and a backup instance rejecting an order as stale because of clock skew. In the event that the primary instance fails, the order would then not exist on the backup.
In addition to the risk of state divergence, the Event Sourcing model also has the disadvantage that to recover state, the entire input stream of events needs to be replayed. That means that the longer the application has been running, the longer the recovery time for the application will be from a cold start presuming it was receiving a steady stream of messages. There is a feature on the Talon road map to provide the ability to checkpoint an application's state to reduce recovery time, but it is another consideration that should be taken into account before electing to use the event sourcing model.
Talon provides several tools to assist applications using Event Sourcing avoid situations such as these, but in general developers should weigh the complexity costs vs. performance requirements.Unlike a State Replication application, the Talon does not need to be made aware of or manage your application's state because it reconstituted on recovery purely through message replay. This means that your application is not required to use ADM modeled state. One downside to Event Sourcing is that for an application to recover from a cold start (e.g. no backup running), the application's entire inbound message stream needs to be replayed from disk. For many classes of applications this is not an issue, but for applications that run 24x7x365 with long lived state such an approach would be infeasible - the disk space and recovery time would be enormous! On Talon's roadmap is a feature that will allow Event Sourcing application's to use ADM modeled state which can be periodically checkpointed in the background to allow older messages in the inbound stream to be discarded.
Coding For Event Sourcing
...
- Modeling Messages and State
- Declaring a main class annotated for EventSourcing
- Writing message handlers to perform business logic.
| Panel |
|---|
|
A Basic App
Model Application Messages
...