Event driven architectures help in tacking asynchronous workflows. This post introduces 5 of the most frequently used patterns which are used when designing Event Driven distributed systems.
1)Pub/Sub pattern
This is the most popular pattern where publishers and subscribers register with a broker. Publishers then send their events to a broker and interested subscribers consume the events from the broker. This pattern comes in useful when events need to be broadcast to several consumers simultaneously and asynchronously. The broker handles the varying rates of production and consumption and ensures that no events are lost.
2)Event Sourcing pattern
Rather than storing the state of a service this pattern recommends storing all the events that led up to the present state. This ensures consistency and reliability. This pattern can come in useful when you need to implement redo/undo operations. It also helps in situations where audits have to be carried out to study the sequence of events which led up to a state.
3)Event Streaming pattern
An event processing engine consumes a voluminous quantity of events and then transforms these events or carries out some computational logic on them before transmitting them to an event sink. This pattern comes in useful for data analytics and setting up data processing pipelines.
4)CQRS pattern
Command Query Responsibility Segregation as the name suggests is a pattern which recommends having separate databases for reads and writes. This ensures better performance, higher availability and independent scalability. Writing to and reading from the same database would hamper performance and eventually could end up derailing the entire system. By having a separate database only for writes you ensure that only those authorised to make those writes can do them and writes are not delayed by any other clients querying the database. You could also scale up or down independently depending on the volume of reads vs writes. This pattern also allows different technologies to be used for the write and read only databases. For eg. You could theoretically use a relational database for your writes and a NoSQL database for your reads.
5)Saga pattern
This pattern comes in useful when running transactions over multiple services. At the end of each local transaction an event is emitted which is then the trigger for the next local transaction in the saga. At any point if a local transaction fails the saga can be rolled back. This pattern comes in useful for high value financial transactions which affect multiple databases and involve several services. The pattern can be used to ensure consistency and reliability of distributed transactions.