Application Architectures
Raymond Lo • December 27, 2022
7 min
Overview
Application architectures are an abstract mapping that describes how an application and all of it's behaviours (authentication, payment, data storage...) interact with each other. Creating a roadmap for your application before building it is critical so that you end up with a product that is scalable and reliable.
There are a variety of architectures types and we will go through what they are and the advantages and disadvantages of each one to get a better understanding of when to use one or the other.
Monolithic
This architecture style was the standard way of developing applications. All the functionality is stored in one codebase and is deployed, scaled and developed as a single unit.
This was a challenge because changing functionality in different parts of the application would require a complete rebuild and redeploy of the application. Because of the tightly coupled nature, making changes can become difficult as the applications grows. The code for different functionalities start becoming more tangled and changing or adding different features could require editing the same code. In addition, every successful change will require a complete rebuild of the application. Your entire application must go through quality assurance before it can be deployed to production as there is always the possibility of breaking other parts of your application when making changes. Therefore, making releases and development a lot slower.
Another challenge was scalability, if certain parts of the application were to receive more load you would have to scale the entire application instead of just the specific part. This created higher infrastructure costs for organizations.
Microservices
The microservices architecture is the more modern approach to building applications and aimed to solve many of the challenges that monolithic approaches faced. This architecture focuses on splitting an application into smaller independent modules that are not dependent on each other, each module is referred to as a microservice.
This loosely coupled structure provides great benefits as each microservice can be scaled, deployed and developed independently. This allows for individual services to be scaled up and down whenever needed, whereas the monolithic approach had to scale the entire application even if it other parts were not in demand. Developers can also work in parallel on separate microservices which speeds up development without the need of rebuilding or redeploying the entire application for every change.
The benefits of the architecture is great, but breaking down the application into independent modules will make your application more complex. In addition, because modules are isolated and independent, they will need a way to communicate with each other. The most basic way is via API calls; each service has it's own API so other services can make HTTP requests to it. However, direct communication between services is not ideal as it couples them together. What if one service is down? Will the entire application stop working? A more common approach is to use an event-driven communication system, which will be discussed later. Configuring your CI/CD pipeline can also get complex depending on the amount of microservices you have for your application.
Event-Driven
The event-driven architecture uses events to communicate between parts in an application. An event is an action that happens in your application. Events are immutable and can contain data. The design is loosely coupled because different parts of the application are not aware of each other. Components are either producing events or listening to them. Event-driven architectures have three key components: producers, brokers, and consumers. Producers detect and send events to the brokers. The brokers analyzes events and pushes them to the correct consumers. Finally, the consumers process the event and complete the action.
An e-commerce site can produce an event when a customer completes payment for their order. This event gets sent to the broker, which then determines which consumers should be notified of order event. Multiple consumers can subscribe to an event. In our scenario, an order event can trigger a service that handles your inventory, shipping or a service that sends an email to your customer and its status could be another possible consumer.
Event driven architectures are great at decoupling and coordinating systems. It can be great when your application has multiple decoupled components, like a microservice architecture, or if your application needs to communicate with other outside systems. Now consider what would happen if one of your services were down. In a non-event-driven architecture, the whole system may stop working because the services are dependent on each other.
Because services have to communicate between an intermediary (events), this affects the performance of your application. Before your other service can run, it must wait to be notified by the broker.