Sergej Khackimullin - Fotolia
3 event sourcing patterns that ease app processing
Examine the pros and cons of three event sourcing patterns that solve certain problems but can introduce new ones in an event-driven architecture.
Event sourcing patterns create application architectures that track changes in a system as events, rather than processing them directly through a central server or database. For example, a new customer order through a commercial web app generates multiple changes, and in the event sourcing architecture, these all trigger events. Changes can also come from within the application, such as in the data. These events are then recorded in an event log, which is the fundamental goal of event sourcing.
Essentially, event sourcing decouples the application change from the record of that change. However, this decoupling means another system needs to hold the request until it processes, potentially through multiple software systems that work at their own pace. When something goes wrong, it can create coordination, reconciliation and debugging problems.
To solve these problems, we turn to three event-driven architecture patterns: queues, publish/subscribe with a service bus and binary star reactors. App architects and developers should understand all three of these basic patterns' advantages and disadvantages, as well as where they work best.
The queue
A queue is another name for a first-in, first-out line. This pattern means that the end client can make a request that the application stores and processes later. The system can deal with spikes in traffic and delays, and catch up later.
The message queue is a piece of middleware that temporarily stores the event information that the applications provide. The server processes these events based on their priority. This way, the database doesn't need to hold the event information and take up critical storage space that could otherwise be used for faster processing.
However, this queuing middleware can add some pesky complexity to the application. The application uses additional server software, which the team must maintain throughout the application lifecycle, to buffer the events. Also, it can only deal with a single event consumer at a time, so the queuing middleware can become a processing bottleneck if the application has to handle too many events at once. This is where the publish/subscribe pattern comes in to play.
Publish/subscribe
Especially in web-scale applications, multiple systems often want to receive messages from a single event. To deal with this, you can configure service bus middleware rather than queuing middleware. The service bus receives the event and then publishes it to any subscribing service or component that wants to use the event. This is the publish/subscribe pattern, also known as multicast or group messaging.
A service bus distributes messages to systems that subscribed to interact with particular events. However, problems can occur with publish/subscribe event sourcing patterns if the system requires high availability. If a client system is down for system maintenance when a message goes out, that message could get lost and the dependent services could fail. To prevent that problem, you can configure service bus systems to demand an acknowledgement of receipt and resend any failed messages until they process correctly. Another approach is to combine the service bus with a queue that is configured to help the message bus store and deal with any failed message transfers.
A third option can help deal with these potential message failures: the binary star reactor.
Downsides of event sourcing patterns
As you look at these patterns, turn your head sideways and squint, figuratively speaking. You'll see that event sourcing patterns break a single logical transaction down into many smaller components. In database terms, a single transaction is atomic, which means that it either all works or it all fails. There are no messy partial-completes to look for and clean up. If the software cannot do that transaction fast enough for your target application consumer, use these patterns to break things up, but expect more complexity in operations and debugging.
The biggest problem with these architectural choices may be observability. When something goes wrong, where it went wrong and why are important questions. Before you jump into a complex hierarchy of events, consider the effort, and how you'll handle issues.
Binary star reactor
The binary star pattern essentially requires that you set up two separate servers: a primary system that manages day-to-day processing and a backup that records transactions and can take over if the primary server fails.
Obviously, this event sourcing pattern doubles the amount of server processing power required for a given application operation. With the cloud options available, adopters might store the backup in the cloud, but that setup still means increased costs -- and adds complexity, too. A binary star pattern also doubles network traffic, which creates more communication overhead than other architectures. If you can afford to set up a binary star pattern, it offers tangible benefits to the software systems. However, consider the costs that this pattern can present.
