This is a blog post from Corey Oliver, one of our software engineers at Dwolla. To hear more from Corey, follow him on Twitter at
Where’s the money coming from and where’s it going? The solution Dwolla implemented to answer this question is an event sourced architecture, which has shown adaptability in many use cases.
This post will walk through why Dwolla chose an event sourced architecture over other solutions for their ACH transfers.
There are two primary approaches or solutions we can consider for tracking money, each with their own pros and cons.
A current-state based architecture is where the application has access to only the current “state of the world.” A good example is storing the balance for an account, say $20, and then replacing that balance with $30 when the account is sent $10. The account balance recorded after each change is the state of the current world aka current-state.
This is the go-to for typical CRUD apps. For one, this solution is well known among existing tools; it is also straightforward making it easy to retrofit to older solutions used by a business.
Now consider events, which signal something that has happened in the outside world. Each event stores its own payload containing information on what happened and at what point in time it happened. The payload is also immutable—it can’t be changed.
An event sourced architecture is one where all state changes in an application are stored as a sequence of events. Many domains in the real world behave like this. Take balancing your checkbook—each debit or credit to your account corresponds to a line in your checkbook. Summing all lines should yield the current balance of your bank account assuming all information is accurate.
Both of these solutions present their own collection of positives and negatives.
As with many things in business, solutions are highly dependent on the problem at hand. For most problems a business will encounter, a current-state based architecture is a solid foundation for building a solution.
But let me emphasize the caveat most. While a current-state based architecture is arguably the most widely used pattern for solving certain business problems, more effective solutions exist.
An event sourced architecture is powerful
Building an event sourced application is less straight-forward than its counterpart, current-state based architecture. It’s also not an option many software developers or product owners are familiar with.
- Applications that are less coupled are not as dependent on one another. This architecture property enables Dwolla to do significant horizontal scalability, and can also provide redundancy and resiliency in cases of system failure or degradation.
- Using this system, events compose an audit log of actions that have occurred in our system. No change in the system occurs unless an event was recorded. Also, we not only have the ability to provide the current state of the system, but also know how and by what means it got there.
- You can build applications on top of events that synthesize into the event data. Some examples of this include:
- reconciling user financial data against funds held at a financial institution
- identifying fraudulent activity
- displaying transaction records and payment activity
Why should you care?
Finance is a crucial part of everyone’s life. This includes account holders at Dwolla. Using an event sourced architecture allows us to track financial events and generate the audit log to confirm them. It maintains the integrity of the information.
So where’s the money? Tracking money in a system is a complex endeavor. At Dwolla, an event sourced architecture has proven beneficial over alternative methods for modeling money ownership—organizations should consider their needs and determine whether an event sourced architecture is an effective and competitive solution for addressing their business problems.
Interested in how your business could be utilizing the Access API within your platform or application? Reach out to our sales team.