An Overview Of Monolithic, Service Oriented And Event Driven Architectures
People rightly believed (although maybe a bit too optimistically at first) that the advent of the Internet would bring about a revolution in the realm of commerce. Following the dotcom boom, a new business model materialized, one in which people and companies could consume services remotely via the Internet. The latter is known as Software as a Service or SaaS.
SaaS has completely changed the way we interact with businesses on a day to day basis. For instance, it wasn’t until recently that we had to visit our local branch every time we wanted to do any kind of banking. Now, we can do all of our banking at the odd hours of the day from the comfort of our own home.
Most SaaS providers like the social media giants Twitter and Facebook as well as e-commerce companies such as Amazon started out by creating monolithic applications.
Monoliths
There are three main aspects to a monolithic software application.
Data interface
A persistent store for data in the form of a database such as MySQL, MSSQL Server, PostgreSQL, etc… The latter might be used to store things like user credentials, product inventory and transactions.
User interface
The user interface is the bridge between the users and the underlying business logic. In the case of Facebook and Twitter, the user interface would consist of their websites and mobile applications. Clients can make request or upload data by performing some kind of action such as clicking, submitting a form, etc…
Business layer
The business logic layer exists because more than just CRUD (Create-Read-Update-Delete) is required by an application. Business logic is used to perform trivially simple tasks (i.e. calculation of sales tax) to the highly complex tasks (i.e. Determine which pages on the entire internet best capture the essence of the search terms).
In a monolith, all of the different layers are tightly coupled. In other words, there is a single code base and database for the entire application.
The problem with monoliths is that they’re difficult to scale and maintain. Therefore, the people working at the large SaaS providers came up with what is now called the service oriented architecture.
Microservices
In a service oriented architecture, the application is built as a suite of modular services. Each module supports a specific business function and uses APIs to communicate between other sets of services. Every microservice is self contained and has its own persistent store.
Some examples of Microservices include:
- Authentication Service —Authenticates customers
- Catalog Service — Manages products inventory
- Payment Service — Finalizes payments
- Shipping Service — Ships ordered products
Since microservices are loosely coupled, developers can make changes to the implementation of a service without any downstream impact.
Event Sourcing
There are times when we don’t just want to view the current state of the system but what lead up to it. Event Sourcing ensures that all changes to application state are stored as a sequence of events.
When applying event sourcing, if a user a changes their address, we create and store an event record. We then process that record in order to make the change to the application state.
Event sourcing provides numerous advantages. Among these include the ability to discard the application state completely and rebuild it by re-running the events from the event log on an empty application.
Suppose we built a microservice to process all of the transactions on our e-commerce platform. Whenever a user makes a purchase on our website, the data related to that transaction is sent to the backend. The transaction service then takes this information, creates a record for it and updates the database to reflect the amount of items in stock.
Now let’s say there are multiple other microservices that want to access these transactions to perform some kind of actions. These might include:
- A notification service that automatically sends a confirmation email to users
- A shipping service that sends a message with the product information and the customer’s address to the people in charge of distribution
- A payment service that will interact with the customer’s bank to finalize the transaction
We could start off by exposing an endpoint that gives a list of each event that happened in a easy to consume JSON format. The consumers would then look at these event feeds and pull from them at whatever frequency they need.
The problem with this approach is that every consumer must contain coordination logic to handle the following scenarios.
- How do we manage competing consumers trying to access the event feed at the same time.
- How do we make sure we only process events once
- How do we make sure we spread the load across many instance
Rather than have every microservice handle these problems, we can make use of a separate system (i.e. event bus) that takes care of all the complexity surrounding the storage and management of events.
Final thoughts
SaaS has revolutionized the way businesses interact with customers. Although, from the customer facing point of view, there appears to have been little to no change in the past decade, a lot has evolved behind the scenes. When starting out, it makes sense to build a monolithic application. However, as your company grows you might want to consider migrating over to a service oriented architecture for scalability and maintainability. If you find yourself needing to react to events in real time or just want to keep track of when events took place, you might want to pursue event sourcing. As opposed to having every microservice manage the complexity surrounding events, we can use a tool like Kafka.
Cory Maklin
_Sign in now to see your channels and recommendations!_www.youtube.com