System Design Interview Cheat Sheet: The 12 API Design Patterns You Need to Know
Master the architecture of distributed systems. Learn the 12 essential API design patterns including Backend for Frontend (BFF), Circuit Breakers, CQRS, Database-per-Service, and the Saga Pattern.
This blog covers:
12 essential API patterns
visual illustrations
API patterns cheatsheet
Knowing what an API is helps you write code.
Knowing how to organize them helps you build systems.
Most developers learn the definitions early on. You understand what a GET request is, how JSON works, and what an endpoint looks like.
However, placing these pieces together into a system that handles millions of users is a different challenge entirely. It is what separates junior developers from senior architects.
This guide explores the structural, reliability, and communication patterns used to scale modern backends. We will move from basic organization to advanced distributed coordination.
Part 1: Structural Patterns
These patterns determine how your system is organized. They decide how a request enters your system, finds the right service, and how the services themselves are grouped.
1. BFF (Backend for Frontend)
Modern applications often have multiple interfaces.
A system might have a mobile app, a web app, and a third-party integration. Each of these clients needs different data. A mobile screen is small and needs less data to load quickly over mobile networks. A desktop web page is large and needs detailed information.
If a single general API is used for everything, it creates a problem called “over-fetching.” The mobile app receives a massive JSON object but only uses 10% of it. This wastes battery and bandwidth, making the app feel slow.
The Solution
The Backend for Frontend (BFF) pattern suggests creating a specific backend service for each frontend. The mobile app talks to the “Mobile BFF.” This service optimizes the data specifically for the mobile interface, stripping out unnecessary fields. The web app talks to the “Web BFF,” which aggregates more detailed data for the desktop view.
2. API Gateway
In a microservices architecture, a system might contain 50 distinct services.
One handles users, one handles payments, and another handles inventory.
If the client (the user’s app) talks to these services directly, it becomes a maintenance nightmare.
The client needs to know the URL of every single service.
If a service moves to a new server, the client application must be updated. It also creates a security risk because every service must expose a public endpoint and handle its own authentication.
The Solution
An API Gateway acts as the single entry point for the system. The client sends all requests to the Gateway.
The Gateway looks at the request and routes it to the correct internal service. It also handles cross-cutting concerns: it checks if the user is authenticated, limits how many requests a user can make, and handles SSL termination.
3. Sidecar Pattern
Microservices are supposed to be small and focused on one business task. However, every service needs common functionality. They all need to log errors. They all need to report metrics. They all need to handle encrypted network traffic (TLS).
If this code is written inside every service, it leads to massive code duplication.
If the logging logic needs an update, every single service must be recompiled and redeployed. This slows down development significantly.