Why Event Driven Architecture Works for Courier
If you’re part of a small engineering team working on the first release of an application, at some point there will be a discussion and a choice about the app’s backend architecture. Depending on the architecture, the team will succeed and struggle in scaling with it. The impact of the chosen architecture includes:
These are several of many second and third order effects that come out of choosing the first architecture for the app. At Courier, we chose to implement an event driven architecture (EDA) backed by AWS for our backend to ensure we could scale with many of the vectors listed. The next couple sections will cover what is EDA at a high level, why EDA fits Courier’s engineering needs, and the benefits & struggles we’ve experienced for the first year.
What is EDA
Event driven architecture is a choice to design software around events. Events typically represent a change of state that occurred in the past. A part of the app will dispatch events for each state change, and there will be one to many reactions to the event. Reactions include changing the view of a read store, invalidating cache, sending a notification, exposing the data via webhook to its consumers, or triggering another business process. Event driven architectures promote a highly decoupled system environment because once the system dispatches the event, it doesn’t need to know what happens afterwards. It all allows for independent work on the code that can react to the event. There is coupling though at the event itself. If there is a destructive change to the shape of the event, all the systems that react to the event will need to change to correctly process it.
Courier’s Needs and Why We Chose EDA
Courier’s main focus is to help customers quickly design notifications and deliver them through our send endpoint. Behind the endpoint exists a set of processes that takes the notification and determines what recipients will receive in the end. Along each step of the process, we need to raise events that other parts of our app will subscribe and handle. Some of these handlers include rendering read only views of our message, hydrating our logs, and moving the notification from a transient state to an end state.
Based on what I said in the previous paragraph, there is a cohesive relationship with our engineering needs and what EDA offers for a guideline. Another reason we chose EDA is that AWS provides up to two event streams off of DynamoDB giving us an easy mechanism to raise events and put them into other services in AWS such as Kinesis where we can set up one to many observers.
Benefits and Struggles with EDA via AWS
With choosing EDA, the team at Courier gained many benefits that’s helped us, but we also ran into a few challenges.
Some of the benefits include:
Some of the struggle we had were:
Choose the Right Architecture
Based on our product values in delivering messages based on customer events, it made sense for us to choose EDA. We believe we and the architecture will scale as our product adds more features. Even with our early struggles with it, the benefits of our choice outweigh the cons. Part of choosing the right architecture is matching what your business needs not only in the short term but for the long term too.
If you find our architecture and what we do here in interesting, see our open roles! We're always looking for great engineering talent.
More from Engineering
Who Knew Email Subjects Are So Complicated
Here is our journey into email subjects upon finding out that Microsoft Outlook didn’t work with certain...
June 10, 2021
The Three Things to Never Build In Your App: Authentication, Notifications, and Payments
In this post, we use Auth0’s post-user registration hook and Courier’s automations feature to learn how ...
May 13, 2021