We should use events much more often in software systems, Randy Shoup declared in a recent blog post about how events should be first-class citizens in systems. He believes we often underestimate the value of events as a tool, and consequently often miss the advantage they could give us. One example is that events can help us decouple parts of a system so that we can reason about them independently.
Shoup works as VP of Engineering at Stitch Fix, which has an environment with more than 70 separate application and services dealing with all aspects of the business. One example of their use of events is a moderately complicated workflow that starts with a client ordering a set of clothes which are then selected by a stylist (a fix delivery). This workflow is made up of several steps, including ordering, selecting items by the stylist, delivery, and possibly a return of some items by the customer. They have implemented the workflow as a state machine and use events to transition from one state to the next. This is quite straightforward, but they also record every step in the actual flow instead of just the current state. This gives them the opportunity to look at the history of a workflow; for example, the steps it has gone through and how long each step has taken. They have a data science team the same size as engineering, and for them this is very important data.
In a microservices architecture like the one Shoup describes, a service may both consume and produce events. When describing the interface, Shoup therefore finds it necessary to include events for a complete definition:
- Synchronous request-response operations, for example using REST and JSON, or gRPC
- Events produced
- Events consumed
- Bulk read and writes, for instance extracting data for use in some analytics tool
When state transitions on entities are represented by events, these events become a record of history. A logical next step may then be to remove storing current state and just rely on the events for recreating the state, a technique called event sourcing. Shoup refers to Greg Young, an authority on the subject, and others. He also refers to tools like Kafka and Akka, both used in distributed, event based systems.
In Shoup’s experience, developers often see events as complicated and counterintuitive, especially for those used to building 3-tier applications. Terms like eventual consistency and asynchronous are commonly used together with events, which may increase the feeling of complexity. Shoup believes though that the idea of events is common to all developers, and refers to software development where code is submitted to version control, code is tested and deployed, all in a past tense exactly how events should be named. For Shoup, events really are part of what developers do on a daily basis.
At QCon New York 2017 Shoup talked about Managing Data in Microservices which includes a part on communication only through events.
