AlgoInsight

Free lesson · System Design Crash Course

The Five-Component Mental Model

Easy13 min readsystem-designhlddistributed-systems

Lesson 1.3 - The Five-Component Mental Model

The most important lesson of this module.

If I could give you only one thing from this entire course - one mental model, one framework, one way of seeing systems - it would be this lesson. Because once you internalize the five components, every architecture diagram you'll ever see becomes legible. Every system you encounter at work decomposes into the same five primitives. Every interview question can be approached the same way.

Here's the promise: by the end of this lesson, you should be able to look at any architecture diagram - Netflix, Stripe, Uber, your company's internal stuff - and see the same five categories of components. You'll know what each one does, what can go wrong with it, and how they connect. This isn't a complete view of system design (there's a lot more nuance), but it's the foundation you'll build everything else on top of.

Let me introduce them.

The Five Components

Every meaningful software system has five categories of components:

  1. Clients - the things that send requests in
  2. Gateways - the things that receive those requests and route them
  3. Services - the things that actually do the work
  4. Data stores - the things that hold the data
  5. Infrastructure - the operational glue that keeps it all running

That's it. Five categories. Every box in any architecture diagram you'll see falls into one of these.

Let me show you the picture first, then we'll walk through each:

flowchart LR
    subgraph Clients["1. Clients"]
        Browser["Web Browser"]
        Mobile["Mobile App"]
        API["API Consumer"]
    end

    subgraph Gateways["2. Gateways"]
        DNS["DNS"]
        CDN["CDN"]
        LB["Load Balancer"]
        APIG["API Gateway"]
    end

    subgraph Services["3. Services"]
        Web["Web Service"]
        Auth["Auth Service"]
        Order["Order Service"]
        Pay["Payment Service"]
    end

    subgraph DataStores["4. Data Stores"]
        DB["Database"]
        Cache["Cache"]
        Queue["Message Queue"]
        Blob["Object Storage"]
    end

    subgraph Infra["5. Infrastructure"]
        Monitor["Monitoring"]
        Deploy["Deployment"]
        Secrets["Secrets Mgmt"]
        Logs["Logging"]
    end

    Clients --> Gateways --> Services
    Services --> DataStores
    Infra -.-> Services
    Infra -.-> DataStores
    Infra -.-> Gateways

    style Clients fill:#34d399,stroke:#10b981,color:#000
    style Gateways fill:#fbbf24,stroke:#f59e0b,color:#000
    style Services fill:#a78bfa,stroke:#8b5cf6,color:#000
    style DataStores fill:#fb7185,stroke:#f43f5e,color:#000
    style Infra fill:#94a3b8,stroke:#64748b,color:#000

A diagram showing the five-component mental model for any software system. On the left, clients  - web browsers, mobile apps, API consumers  - the things that send requests in. They connect to gateways  - DNS, CDN, load balancers, API gateways  - which receive requests and route them. Behind the gateways are services  - the actual application code doing business logic, like a web service, auth service, order service, payment service. The services talk to data stores  - databases, caches, message queues, object storage  - which hold the actual data. And running alongside everything is infrastructure  - monitoring, deployment systems, secrets management, logging  - the operational glue that keeps the whole thing running. Every architecture diagram you'll ever encounter has these five categories. The boxes vary, the technologies vary, the connections vary, but the categories don't.

Let me walk through each one now, in plain English.

1. Clients

Clients are the things that initiate requests. They're outside your system, sending traffic in. Your job is to respond to them.

The most common types of clients:

Web browsers. When someone opens chrome.google.com or your-product.com, their browser is a client. It sends HTTP requests to your servers and renders the HTML/JS/CSS it gets back.

Mobile apps. Native iOS or Android apps installed on phones. They typically send API requests (JSON over HTTPS) to a backend, then render the responses in native UI.

Other servers (API consumers). If your product offers an API that other companies integrate with, those companies' servers are clients. A merchant integrating Stripe is a "client" of Stripe's API.

Internal services calling each other. In larger systems, services often call each other. When the "Order Service" calls the "Inventory Service" to check stock, it's acting as a client of the Inventory Service.

Bots, scripts, scheduled jobs. Anything that makes requests programmatically - a cron job hitting your API, a monitoring system polling for health, a web scraper.

You don't usually design the clients themselves in HLD - they're given. What you design is how your system responds to clients. But you have to know what kinds of clients you're dealing with, because they affect the rest of your design:

The first question of any HLD is: who are the clients? Once you know that, a lot of downstream decisions get easier.

2. Gateways

Gateways are the entry points to your system. When a client wants to send a request, it doesn't usually connect directly to your application code. It connects to a gateway first, which routes the request appropriately.

Why do gateways exist? Because doing things at the entry point is way more efficient than doing them everywhere. Things you want to do once, for every request: TLS termination, authentication checking, rate limiting, request logging, routing to the right service. Gateways handle all of these in one place.

The most common types of gateways:

DNS. When a client wants to connect to "example.com," it first asks DNS what IP address that name maps to. DNS is technically a gateway in that it directs traffic. You don't usually think of it that way, but it's the first thing every request encounters.

CDN (Content Delivery Network). Like CloudFront, Cloudflare, or Akamai. CDNs cache content at edge locations around the world, so users get fast responses without their request crossing the globe. Common for serving images, videos, CSS, JavaScript.

Load Balancer. Like Nginx, HAProxy, AWS ALB. Takes incoming requests and distributes them across multiple application servers. Important: if you have more than one server, you need a load balancer.

API Gateway. Like AWS API Gateway, Kong, Apigee. A more sophisticated gateway that handles cross-cutting concerns for APIs: authentication, rate limiting, request transformation, monitoring. Sits in front of your services.

Reverse Proxy. A general term that covers load balancers, API gateways, and similar tools. The "reverse" part means it's proxying for the servers (vs a forward proxy that proxies for clients).

Most production systems have multiple gateway layers stacked:

flowchart LR
    Client["Client"]
    DNS["DNS<br/>(name → IP)"]
    CDN["CDN<br/>(static content)"]
    LB["Load Balancer<br/>(distribute traffic)"]
    APIG["API Gateway<br/>(auth, rate limit)"]
    Service["Service"]

    Client --> DNS
    Client --> CDN
    Client --> LB
    LB --> APIG
    APIG --> Service

    style DNS fill:#fbbf24,stroke:#f59e0b,color:#000
    style CDN fill:#fbbf24,stroke:#f59e0b,color:#000
    style LB fill:#fbbf24,stroke:#f59e0b,color:#000
    style APIG fill:#fbbf24,stroke:#f59e0b,color:#000

A diagram showing the typical chain of gateways in a production system. The client first resolves the domain name through DNS. For static content like images, the request goes to a CDN. For dynamic requests, it goes through a load balancer that distributes traffic across multiple application servers. The load balancer often hands off to an API gateway that handles authentication and rate limiting before passing the request to the actual application service. Multiple gateway layers, each doing its specific job, all between the client and the actual service code. This stacking is normal  - at large companies, the gateway chain can be even longer with WAFs, regional load balancers, edge functions, and other layers.

You probably won't build most gateways from scratch - you'll use existing tools (AWS ALB, Nginx, Cloudflare). But understanding what each does and where it sits in the chain is essential HLD knowledge.

3. Services

Services are where the actual work happens. This is your business logic - the code that handles a user signing up, processes a purchase, generates a recommendation, sends a notification. When people say "the application," they usually mean the services.

A service is, basically, a deployable unit of code that does some specific job. It receives requests, does something useful, and returns a response.

A few possible shapes:

Monolithic service (one big service). All the business logic in one application, deployed as a single unit. Common at smaller companies and earlier-stage startups. Less complex operationally; harder to scale specific parts.

Microservices (many small services). Each business function is its own service. An "Order Service" handles orders. A "Payment Service" handles payments. A "User Service" handles user data. They communicate via APIs. Common at larger companies.

Serverless functions. Like AWS Lambda or Google Cloud Functions. Tiny services that run only when triggered. Don't run continuously like traditional servers do.

Background workers. Services that don't handle user requests directly. Instead, they process messages from a queue, run scheduled jobs, or perform batch work. Important: these are still services, just with a different trigger than HTTP requests.

Whatever the shape, services are where your business is encoded. They're the part of the system that's most uniquely yours. The databases and load balancers might be off-the-shelf; the services are the code you write.

In HLD work, you spend a lot of time thinking about:

The Order Service in our diagram is a service. The Auth Service is a service. The Payment Service is a service. They're separate boxes because they do separate jobs.

A key principle: a good service has a clear, focused responsibility. "User authentication" is a focused responsibility. "Everything related to users" is too broad. Knowing where to draw service boundaries is one of the hardest things in HLD, and we'll come back to it many times in the course.

4. Data Stores

Interactive animation: Different data, different store: relational, document, key-value, wide-column, caches, queues, object storage and search.

Data stores are where the data lives. Services typically don't hold data themselves (they restart and lose any in-memory state). The data lives in something more persistent.

The major categories:

Databases. Where structured data lives. The most common:

Caches. Fast in-memory data stores used to speed up access to data that's expensive to compute or fetch. Common tools: Redis, Memcached. We have a whole module on caching later.

Message queues. For asynchronous work. A producer puts a message on the queue; a consumer takes it off later and processes it. Common tools: RabbitMQ, AWS SQS, Apache Kafka (though Kafka is technically a streaming platform).

Object storage. For files, images, videos, backups. Examples: AWS S3, Google Cloud Storage, Azure Blob Storage. Designed for huge amounts of unstructured data.

Search indexes. Specialized for text search and complex queries. Examples: Elasticsearch, Algolia.

Time-series databases. For data with timestamps - metrics, logs, IoT sensor data. Examples: InfluxDB, TimescaleDB, Prometheus.

In any real system, you'll use multiple of these. A typical web app might have:

Each one is a different type of data store, each appropriate for a different kind of data. Choosing the right type for each job is a big part of HLD work. There's even an entire course (System Design Advanced) dedicated to going deep on each one.

For now, just internalize: services don't hold data; data stores do. That separation is fundamental.

5. Infrastructure

Infrastructure is the operational glue. It's the stuff that keeps the system running, observable, and deployable. You don't always think of these as part of "the system," but they absolutely are. Without them, the other components can't function in production.

The major categories:

Monitoring and metrics. Tools that watch the system and tell you when something's wrong. Examples: Prometheus, Datadog, New Relic, Grafana. They collect numbers about how the system is performing - request rates, error rates, latencies.

Logging. Where logs from all your services get collected, stored, and made searchable. Examples: Splunk, ELK (Elasticsearch + Logstash + Kibana), Loki, CloudWatch.

Distributed tracing. Like logging, but for tracking a single request across many services. Examples: Jaeger, Zipkin, OpenTelemetry. Crucial for debugging in microservice architectures.

Deployment systems / CI/CD. Tools that take code and put it into production. Examples: Jenkins, GitHub Actions, CircleCI, Spinnaker, Argo CD.

Configuration management. Tools that manage configuration across services. Examples: HashiCorp Consul, etcd, Spring Cloud Config.

Secrets management. Tools that securely store and distribute passwords, API keys, certificates. Examples: HashiCorp Vault, AWS Secrets Manager, Doppler.

Container orchestration. Tools that manage containers (Docker) across many machines. Examples: Kubernetes (K8s), Amazon ECS, Docker Swarm.

Service mesh. Tools that handle service-to-service communication in microservice architectures. Examples: Istio, Linkerd, AWS App Mesh.

You typically don't write these from scratch. You use existing tools, configure them for your needs, and integrate with them. But you can't ignore them in HLD work - every production system has them, and the choices you make about them affect everything else.

A useful way to think about it: infrastructure is what lets you sleep at night. Without monitoring, you don't know if your system is broken until users complain. Without good deploys, every release is risky. Without secrets management, your security is fragile. Infrastructure is what makes the system operable, not just functional.

Reading a Real System with This Lens

Let me show you how this mental model applies to a real product. Consider Instagram. What might its HLD look like, decomposed by the five components?

Clients:

Gateways:

Services:

Data stores:

Infrastructure:

You don't need to know the exact tools to understand the shape. Every major product on the internet decomposes into these five categories. Once you can do this decomposition, you can read any architecture document and orient yourself quickly.

Interactive animation: Instagram through the five-component lens: its clients, gateways, services, data stores and infrastructure, at planet scale.

A Common Beginner Mistake

When beginners first encounter the five-component model, a common mistake is to think the components are strictly separated. They're not. There's overlap.

For example:

The categories are useful even though the boundaries are fuzzy. Use them as a starting framework. When you encounter a component that fits multiple categories, that's fine - it just tells you the component has multiple responsibilities. You'll get better at this with practice.

Why This Mental Model Is Powerful

Three reasons:

One: it gives you a checklist. When designing a new system, you can systematically ask: "What are the clients? What gateways do I need? What services? What data stores? What infrastructure?" Each question prompts the relevant decisions.

Two: it makes any architecture diagram understandable. When you see a diagram in a blog post or interview, you can mentally categorize each box. "OK, this box is a service. This box is a data store. This box is a gateway." Once categorized, the relationships become clearer.

Three: it scales from tiny systems to massive ones. A single-server hobby app has the same five categories (just with simpler components). A planet-scale system like Google Search has the same five categories (with much more complex components). The framework holds throughout.

We'll use this mental model constantly throughout the rest of this course. When we get to Module 4 (Networking), we're zooming into how Clients talk to Gateways. When we get to Module 12 (Database Fundamentals), we're zooming into Data Stores. When we get to Module 24 (Architectural Patterns), we're talking about how Services are organized. Everything connects back to these five primitives.

Six Takeaways from This Lesson

  1. Every system has five categories of components: clients, gateways, services, data stores, and infrastructure.

  2. Clients initiate requests; gateways receive and route them; services do the work; data stores hold the data; infrastructure keeps everything running.

  3. The categories are useful even though the boundaries are sometimes fuzzy. Some components fit multiple categories - that's fine.

  4. In HLD work, you go through the categories systematically. What clients? What gateways? What services? What data stores? What infrastructure?

  5. This model scales from hobby apps to planet-scale systems. The categories are the same; the complexity inside each one varies.

  6. You'll use this mental model in every subsequent module of this course. It's the framework everything else hangs on.

Try It

Exercise: Warmup (10 minutes). Pick a product you use every day (Spotify, Netflix, WhatsApp, your bank's app - anything). On paper, list at least one example component for each of the five categories.

Exercise: Core (20 minutes). Find an architecture diagram on a real company's engineering blog (Netflix tech blog, Discord engineering blog, Stripe blog). Identify which boxes fall into which of the five categories.

Exercise: Stretch (40 minutes). Pick a simple system you might build (a personal todo app, a recipe sharing site, a small e-commerce shop). Sketch its HLD using the five-component lens. What are the clients? Gateways? Services? Data stores? Infrastructure?

What's Next

Lesson 1.4 turns reading-other-companies'-architectures into a discipline. We'll cover how to actually learn HLD by reading the published architectures from companies like Netflix, Stripe, Discord, and GitHub.

Back to System Design Crash Course