System Components

Basic System Design
≈ 2 min read

A request passes through several layers

When a user opens an application, the request rarely reaches the required service instance directly. The system first needs to resolve an address, may serve data from a nearby node, pass through entry components, and then reach the application that executes the business logic.

In this section, we will cover the main components commonly found along that path. The goal is not just to memorize their names, but to understand what problem each layer solves and where its responsibility ends.

What we will cover

  • DNS. We will see how a domain name becomes an address a client can send a request to, and why DNS participates in system availability and routing.
  • CDN. We will learn how to serve content closer to users and reduce load on the system's central infrastructure.
  • Reverse Proxy. We will see why an intermediary server is placed in front of an application and which shared concerns fit naturally on this layer.
  • Load Balancer. We will learn how to distribute incoming traffic across multiple application instances and exclude unavailable nodes.
  • API Gateway. We will examine a single entry point for APIs where routing and shared access policies can be centralized.
  • Application Server. We will look at the layer where application logic executes and a request is processed after passing through the entry infrastructure.
  • Service Discovery. We will understand how services find one another when instances dynamically appear, disappear, and change addresses.

The topics follow the natural path of a request: from address resolution and content delivery to the entry layer, application instances, and communication between services. After that, the next parts of the system will be easier to discuss because it will be clear where they connect to the overall design.

Not every system needs all of these components. Architecture starts with requirements: an additional layer is useful only when it solves a real problem.