Backend system design scope

Backend system design is the practice of deciding how a server-side application is structured, how its components communicate, and how it handles data at rest and in motion. It sits between high-level design (which picks the boxes in the architecture diagram) and low-level design (which picks the classes and functions inside each box). This series focuses on the middle layer: the decisions that shape APIs, databases, caches, jobs, and integrations.

What this series covers

The series walks through eight topics that appear in nearly every production backend:

1. This article maps the scope and the stack of concerns.
2. REST API design covers resource modeling, HTTP semantics, and pagination.
3. Authentication and sessions covers tokens, OAuth, and multi-device login.
4. Database design covers schema modeling, indexing, and connection management.
5. Caching covers Redis patterns, distributed locks, and cache warming.
6. Background jobs covers task queues, retries, and dead letter queues.
7. File storage covers uploads, presigned URLs, and CDN serving.
8. Search integration covers index syncing, relevance tuning, and autocomplete.

Each article is self-contained but builds on the previous ones. By the end you will have a mental model for designing backend systems that are correct, observable, and maintainable.

How backend design connects to HLD and LLD

High-level design (HLD) answers “what components exist and how do they connect?” Low-level design (LLD) answers “how does this single module work internally?” Backend design answers the questions in between.

graph TD
  HLD["High-Level Design<br/>Components, protocols, deployment"]
  BD["Backend Design<br/>APIs, schemas, caching, jobs, auth"]
  LLD["Low-Level Design<br/>Classes, functions, algorithms"]

  HLD --> BD
  BD --> LLD

  style HLD fill:#4a90d9,color:#fff
  style BD fill:#e8a838,color:#fff
  style LLD fill:#50b86c,color:#fff

Backend design bridges HLD decisions and LLD implementation.

Consider building an e-commerce platform. HLD decides you need a product service, an order service, and a payment service. LLD decides how the order service validates line items internally. Backend design decides:

• What the order API looks like (REST? GraphQL? What resources?).
• How the order schema is indexed so listing a user’s orders is fast.
• How the payment callback is authenticated.
• Whether order confirmation emails are sent synchronously or through a job queue.

These are not architecture questions and not implementation questions. They are design questions that affect correctness, performance, and operability.

The stack of concerns

Every backend system deals with four layers of concern. They are not independent; a decision in one layer constrains choices in others.

Compute

Compute is where your application logic runs. The key decisions are:

• Runtime model: threads, event loop, or processes. Node.js uses an event loop. Java typically uses threads. Python workers often use processes.
• Scaling unit: do you scale by adding instances (horizontal) or by adding CPU/RAM to one machine (vertical)?
• Statelessness: can any instance handle any request, or does a request need to land on a specific instance? Stateless compute is easier to scale.

A stateless API server behind a load balancer is the most common pattern. It pushes all state into the storage layer and makes horizontal scaling straightforward.

Storage

Storage is where data lives between requests. This layer includes:

• Primary database: the source of truth. Usually relational (PostgreSQL, MySQL) for transactional workloads.
• Cache: a fast, volatile store (Redis, Memcached) that reduces database load.
• Object storage: blobs like images, PDFs, and videos (S3, GCS, Azure Blob).
• Search index: a specialized store (Elasticsearch, OpenSearch) optimized for full-text queries.

Each storage system has different consistency, durability, and latency characteristics. Choosing the right one for each use case is a core backend design skill.

Network

Network concerns include:

• API protocols: REST, gRPC, GraphQL, WebSockets. Each has trade-offs in tooling, performance, and developer experience.
• Service-to-service communication: synchronous calls vs asynchronous messaging. Synchronous is simpler. Asynchronous is more resilient.
• Load balancing: distributing requests across compute instances. Layer 4 (TCP) vs Layer 7 (HTTP) balancing.
• DNS and CDN: how clients find your servers and how static assets reach them fast.

Security

Security is not a separate phase. It is woven into every layer:

• Authentication: verifying identity (tokens, OAuth, API keys).
• Authorization: checking permissions (RBAC, ABAC, policy engines).
• Transport security: TLS everywhere, certificate management.
• Input validation: rejecting malformed data before it reaches business logic.
• Secrets management: keeping credentials out of code and config files.

graph LR
  subgraph "Stack of Concerns"
      direction TB
      S["Security<br/>Auth, TLS, validation, secrets"]
      N["Network<br/>APIs, messaging, load balancing"]
      ST["Storage<br/>DB, cache, object store, search"]
      C["Compute<br/>Runtime, scaling, statelessness"]
  end

  S --- N
  N --- ST
  ST --- C

  style S fill:#e74c3c,color:#fff
  style N fill:#3498db,color:#fff
  style ST fill:#2ecc71,color:#fff
  style C fill:#f39c12,color:#fff

The four layers of backend concern. Security spans all others.

Quantifying the layers

Different projects weight these concerns differently. A data-heavy analytics backend spends most of its design effort on storage and compute. An API gateway spends it on network and security. Here is a rough breakdown for three common backend types:

These numbers are approximate. The point is that backend design is not one-size-fits-all. The relative importance of each concern depends on what you are building.

How to use this series

Each article follows a consistent structure:

1. Core concept: what the topic is and why it matters.
2. Design patterns: the common approaches and when to use each.
3. Trade-offs: what you gain and what you give up.
4. Diagrams: visual models of the key flows.
5. What comes next: a pointer to the next article.

Read them in order if you are new to backend design. Jump to specific articles if you need to solve a specific problem. Either way, the goal is the same: build a mental toolkit for making backend design decisions quickly and confidently.

Common mistakes in backend design

Before diving into the series, here are patterns that cause the most pain in production:

Designing for scale you do not have. Premature optimization in backend design looks like sharding a database before you have 100 users, or introducing a message queue when a simple function call would work. Start simple. Add complexity when measurements justify it.

Ignoring failure modes. Every network call can fail. Every database query can be slow. Every cache can be cold. Design for the unhappy path first, then make the happy path fast.

Leaking abstractions across layers. When your API response includes database column names, or your job queue knows about HTTP status codes, you have coupled layers that should be independent. Clean boundaries make systems easier to change.

Skipping observability. If you cannot see what your system is doing in production, you cannot fix it when it breaks. Logging, metrics, and tracing are not optional extras. They are core design concerns.

What comes next

The next article covers RESTful API design: resource modeling, HTTP verbs, status codes, pagination, and versioning. APIs are the front door of every backend, so getting them right sets the foundation for everything that follows.