Master System Design: 30 Core Concepts Every Backend Engineer Must Know

Spring Boot 3 Practical Case Collection

Environment: SpringBoot 3.4.2

1. Introduction

System design can feel overwhelming, especially for newcomers who don’t know where to start. Once you understand the core concepts and building blocks, designing scalable systems for interviews or real‑world projects becomes much less intimidating.

This article covers the 30 most essential system‑design concepts every developer should know.

2. Practical Cases

2.1 Client‑Server Architecture

Almost every network application is built on the simple yet powerful client‑server model.

One side is the client—such as a web browser, mobile app, or any front‑end application.

The other side is a continuously running server that waits to process incoming requests.

The client sends requests to store, retrieve, or modify data; the server receives, processes, and returns a response.

A key question arises: how does the client know where the server is?

2.2 IP Address

The client needs an address to locate the server; on the Internet, computers identify each other via IP addresses, which act like phone numbers for servers.

Every publicly deployed server has a unique IP address. When a client wants to interact with a service, it must send the request to the correct IP.

Users typically type a domain name, not an IP address.

Remembering numeric IPs for every service is impractical.

Server migrations can change IPs, breaking direct connections.

2.3 DNS

Instead of memorizing IPs, we use human‑friendly domain names. DNS maps these names to their corresponding IP addresses.

When you type pack.com in a browser, your computer queries a DNS server for the IP, then connects to the server using that IP.

You can use the ping command to look up any domain’s IP.

2.4 Proxy / Reverse Proxy

Sometimes a request doesn’t go directly to the server; it first passes through a proxy or reverse proxy.

A proxy sits between the client and the Internet, forwarding requests to the target server and returning the response, while hiding the client’s IP.

A reverse proxy intercepts client requests and forwards them to backend servers based on predefined rules, providing security, load balancing, and hiding server IPs.

2.5 Latency

Every client‑server interaction incurs latency, often due to physical distance. For example, a request from India to a server in New York must travel across the globe, increasing round‑trip time.

Reducing latency can be achieved by deploying services in multiple data centers so users connect to the nearest one.

2.6 HTTP / HTTPS

Web browsers and servers communicate using the HTTP protocol. URLs start with http:// or the secure https://.

HTTPS encrypts data with SSL/TLS, protecting sensitive information from eavesdropping.

2.7 APIs

APIs act as a middle layer that lets clients (web or mobile apps) interact with servers without dealing with low‑level details.

2.8 REST API

REST is the most widely used API style. It is stateless, resource‑oriented, and uses standard HTTP methods (GET, POST, PUT/PATCH, DELETE).

While simple and cacheable, REST can be inefficient for complex data retrieval, often returning more data than needed.

2.9 GraphQL

GraphQL allows clients to request exactly the data they need, reducing over‑fetching. A single query can replace multiple REST calls.

2.10 Database

Databases store and manage large volumes of data that cannot fit in memory, ensuring persistence, consistency, and security.

2.11 SQL vs NoSQL

SQL databases provide ACID guarantees and are ideal for strong consistency (e.g., banking). NoSQL databases offer high scalability and flexible schemas (e.g., Redis, MongoDB, Cassandra).

2.12 Vertical Scaling

Increasing a single server’s CPU, memory, or storage can handle more load, but it has hardware limits, rising costs, and creates a single point of failure.

2.13 Horizontal Scaling

Adding more servers distributes load, eliminates single‑point failures, and is more cost‑effective. Load balancers route traffic among servers.

2.14 Load Balancing

Load balancers sit between clients and backend servers, distributing requests using algorithms such as Round Robin, Least Connections, or IP Hashing.

2.15 Database Indexing

Indexes accelerate query performance by providing a fast lookup table, similar to a book’s index, but they add overhead to write operations.

2.16 Replication

Replication creates read‑only replicas of a primary database. Writes go to the primary; reads are distributed across replicas, improving read performance and availability.

2.17 Sharding

Sharding splits a large database into smaller pieces (shards) distributed across multiple servers, reducing load and improving read/write performance.

2.18 Vertical Partitioning

Vertical partitioning separates a table’s columns into focused sub‑tables (e.g., user profile, login history, billing) to speed up queries that need only a subset of columns.

2.19 Caching

Caching stores frequently accessed data in memory to avoid repeated database reads. The Cache‑Aside pattern checks the cache first, falls back to the database if missing, then populates the cache.

2.20 Denormalization

Denormalization merges related data into a single table to reduce JOINs, improving read speed at the cost of data redundancy.

SELECT o.order_id, u.name, u.email, o.product, o.amount
FROM orders o
JOIN users u ON o.user_id = u.user_id;

SELECT order_id, user_name AS name, user_email AS email, product, amount
FROM orders;

2.21 CAP Theorem

In distributed systems, you can only achieve two of the three guarantees: Consistency, Availability, and Partition tolerance.

CP (e.g., MySQL) prioritizes consistency.

AP (e.g., Cassandra) prioritizes availability.

Eventual consistency allows replicas to become consistent over time.

2.22 Blob Storage

Large binary objects (images, videos, PDFs) are stored in blob storage services like Amazon S3, offering scalability, pay‑as‑you‑go pricing, automatic replication, and easy access via URLs or REST APIs.

2.23 CDN

Content Delivery Networks cache static assets on edge servers worldwide, delivering content from the node closest to the user, reducing latency.

2.24 WebSockets

WebSockets provide a persistent, full‑duplex connection for real‑time communication, eliminating the need for frequent HTTP polling.

2.25 Webhooks

Webhooks let a server push events to another server via HTTP POST when something happens (e.g., payment completed), avoiding polling.

2.26 Microservices

Microservices break a monolithic application into independent services, each handling a single responsibility, with its own database and communication via APIs or message queues.

2.27 Message Queues

Message queues enable asynchronous communication between services, improving resilience and scalability.

2.28 Rate Limiting

Rate limiting caps the number of requests a client can make within a time window, protecting resources and preventing abuse.

2.29 API Gateway

An API gateway centralizes authentication, rate limiting, logging, and routing for multiple microservices, providing a single entry point.

2.30 Idempotency

Idempotency ensures that repeated requests produce the same result as a single request, preventing duplicate transactions.