Purpose of the article: To explain different software architectures

Intended Audience: iOS Developers

Tools and Technology: Anyone

Keywords: Monolithic, Queue, event-based, Microservices

Monolithic and Tiered Architecture

To illustrate monolithic and tiered architecture, let’s consider an example where a user uploads high-quality 4k videos to YouTube. At this point, YouTube generates various levels of quality videos, e.g., 240 px, 360 px, and 480 px. YouTube also stores, manages, and retrieves data to and from the database.

There are a few ways we can architect this solution. The most famous architecture is Monolithic architecture, where all application components are in a single Blackbox.

Here Upload, Processing, Storage, and Manager are all in a single package. This architecture has several considerations because of its single all-in-one entity; if one component fails, it impacts the complete application end to end. Another thing to consider about monolithic architecture is deployment. Since all components are in a single entity, it needs to deploy the complete application. Another consideration is billing. All components of monolithic architectures are always running, and because of that, all components are billed together. So monolithic architecture is the least cost-effective way to architect systems.

1. In Tiered architecture, monolithic is broken apart, and components become a collection of tiers. Each of these tiers can be on the same server, or it can be on different servers. In this architecture, components are still coupled together. The immediate benefit of tiered architecture over monolithic is that these tiers can be vertically scaled independently. For example, the processing tier can increase CPU capacity without increasing the upload and storage tier capacity. Tiered architecture also has some issues.
2. Upload tier expects processing tier to exist and respond.
3. Even if no jobs are to be processed, the processing tier has something to be running.

Queue-based Architecture

In this part of the article, we will discuss a Queue-based design to improve synchronous communication, scaling, microservices, and event-based architectures.

The queue is a system that accepts messages, and messages are received and polled from queues. In most cases, messages are received from the queue in FIFO order.

In Queue-based architecture, the user uploads 4k videos to upload components. Instead of passing directly to the processing tier, videos are stored in the S3 bucket, passing the message to the queue with all relevant information, and finishing the transaction. Here the important part is that the Upload component doesn’t expect an immediate response from the Processing Tier. The queue has decoupled the Upload and Processing tiers. The queue moved the communication between Upload and Processing tier from sync to async.

We have an Autoscaling group on the other side that will process those messages. Initially, the Autoscaling group had no instances, but it has provisioned instances based on the queue length. These instances start polling and retrieves messages from the queue. Once messages are processed, messages will get deleted from the queue, and the Autoscaling group will scale back to the initial number of instances.

In queue architecture, placing queues between two application tiers decouples that application tier. One tier adds a job to the queue and doesn’t care about the health and state of other tiers, and another tier reads jobs from the queue.

Event-based Microservices Architecture

If we continue breaking down the monolithic application into smaller and smaller services, we have microservices architecture. In our example, we have Processed, Uploaded, Storage and Managed microservices.

1. Upload Microservice-Producer
2. Process Microservice-Consumer
3. Storage & Manage-Producer/Consumer

We can also implement these microservices using a queue. The queue can communicate with events between microservices. However, it can be more complicated because of many queues.

In this architecture, when the producer produces the event, it gets added to the event bus through the event router, and the event router delivers those events to the consumer.  We can consider Event bus as a constant flow of information.

Benefits of event-based microservices architecture:

1. Neither the producer nor the consumer waits for things to happen.
2. The producer generates an event when something happens.
3. Consumer consumes eventwhen it is required.
4. Events are delivered to the consumers.

Hope the article helps your architecture framing journey.