Hello, everyone! It’s been a while since I wrote a blog post. Today, I’m exploring the Event-Driven Architecture (EDA), particularly in the context of social protection. EDA’s diverse patterns offer unique solutions for complex problems we see.

Note that I will be taking OpenSPP as an example to explain, as it’s the project I am working on now. Think that there are two major components in OpenSPP: the registry and programs. The registry has all the beneficiary information, and the program handles the entitlements and distribution of a social protection program.

What’s an Event?

Let’s 1st look at what’s an event. In EDA, an ‘event’ is a significant change in the state of a system or an important occurrence that the system should record or react to. For example, an event in a registry could be a change in a beneficiary’s employment status. This event triggers the system to update records, notify other components, or perform specific actions based on the nature of the change(let’s say we want to stop his/her entitlements when he/she has a job). Usually, the publisher puts the event in an event queue to be picked up by the subscribers. It’s the pub-sub pattern we use here.

Now, let’s look at the EDA patterns with relevant examples.

Pattern 1 – Event Notification

This pattern focuses on decoupling systems, which is essential for simplifying interactions between different software system components. Think of it as creating a more streamlined communication process within your architecture. For instance, when a beneficiary’s status changes in the OpenSPP registry (like a change in employment status), an event is emitted. This event prompts the OpenSPP programs to update their entitlements accordingly, ensuring timely and relevant social support.

Pattern 2 – Event-Carried State Transfer

Elevating from basic event notification, this pattern involves events carrying enough data to eliminate the need for additional queries. It’s all about ensuring systems have the necessary data to act without extra communication. Imagine a scenario where a beneficiary’s employment statys changes in the OpenSPP registry. The event carries the old and new address details, enabling the OpenSPP programs to adjust their entitlements without further queries like in the pattern 1. This pattern ensures comprehensive data transfer.

Pattern 3 – Event Sourcing

This is a particular concept where changes are logged as events, enabling systems to rebuild past states. This approach is useful for creating detailed audit trails & debugging. In this pattern, the concepts of “application state” and “log” are crucial. The application state refers to the current status or condition of the system, representing the latest information or data. On the other hand, the log is a comprehensive record of all events or changes that have occurred over time. This log enables the system to rebuild the application state at any point, providing a powerful way to understand the system’s evolution. As an example, this could mean tracking every modification in a beneficiary’s profile. Therefore, the system can build the beneficiary’s profile from the logs without application data(database) at any given point.

Let me tell you a fun fact. If you are using git, you are using event sourcing (kind of) because you can rebuild the state of a repo from the commits.

Pattern 4 – Command Query Responsibility Segregation (CQRS)

This advanced pattern separates the read and write models within a system. It’s a powerful strategy but requires careful implementation to avoid complexity. This could be implemented as one module (command model) handling data entry (like updating beneficiaries’ records) and another module (query model) for data retrieval (reading beneficiaries’ records). CQRS can optimize performance in large-scale systems by separating your CRUD operations (command model and query model).

Incorporating these EDA patterns into social protection systems can significantly enhance efficiency, scalability, and responsiveness if you are planning a large rollout, but it will add additional complexity to your architecture and implementations. Based on my experience, I advise not implementing these patterns unless you really see the technical requirement for it because it can get messy.

That’s it for today, and stay tuned for more deep dives!