Replicated Load-Balanced Services

In this chapter, we want to move one step closer to the real world of distributed systems. We will discuss different architectural patterns that are practically implemented and used in many real-life systems all around the globe. It will help the learners to build a better understanding of distributed systems in practice.

The first pattern we will discuss in this lesson is known as replicated load-balanced services. The name more or less gives away the idea.

Stateless services

The first type of the replicated load-balanced services pattern is stateless services.

Stateless services are ones that don’t require saved state to operate correctly.

Designing Distributed Systems, Brendan Burns

In stateless services, a node does not need additional data pre-populated to serve a request. When a request comes, a stateless service can check the request, fetch some data from a database, and respond with the data. It does not take into account any pre-populated data, possibly from any previous request. The service does not store any state in it. It’s simple—it gets triggered when a request comes, serves the request, and forgets about it.

Think of an application. To serve the application to our users, we will deploy it in a node. When our user base grows, one node will no longer be enough to serve an increasing user base.

To support more users, we will deploy the application in multiple nodes. Any of these nodes is now capable of serving the users. A request can end up in any node, and the response will be as expected.

In stateless services, the nodes do not have any state-related context. They receive a request, probably query some database, and serve the response. They are not managing any state.

An example of stateless services is static content servers (such as CSS, HTML, or Javascript files).