What Are the 5 Types of System Architecture? A Field Guide for Builders
I learned the hard way that most architecture debates are cargo-cult nonsense.
In 2021, my team at SIVARO was building a real-time fraud detection system for a payments processor. We'd spent three months designing this elegant event-sourced microservices mesh. Felt smart. Looked great on a whiteboard.
Then we tried to ship it to production.
The system fell over at 2,000 events per second. The fraud analyst couldn't find transactions in the time it took to make coffee. We'd built the wrong architecture for the job — and we knew it within 48 hours of going live.
System architecture isn't a philosophy. It's a set of trade-offs. You pick the shape that matches your constraints: data volume, latency needs, team size, and how often things break.
What are the 5 types of system architecture? They're not academic categories. They're the five patterns I've seen work (and fail) in production across dozens of systems at SIVARO and with our clients. Let me walk through each one — with the scars to prove it.
Monolithic Architecture
Most people think monoliths are bad. They're wrong.
A monolith is one application where everything runs in a single process. The UI, business logic, data access — all deployed together. Think of a Rails app or a Django project before someone convinced you to split it.
When it works: You have fewer than 10 engineers. Your data fits on one server. Your deployment pipeline is a single git push.
I built the first version of SIVARO's internal dashboard as a monolith in 2019. Three engineers, six months, one Postgres instance. It handled our first 50 clients without a hiccup. We spent zero time on network calls between services, zero time on debugging distributed transactions, zero time on service discovery.
The trade-off: A monolith can't scale parts independently. You want more throughput on the reporting endpoint? You have to scale the whole app — including the login page and the password reset flow. That's wasteful. And deployment risk is concentrated: one bad line in a CSV export function can take down your entire API.
Distributed computing literature calls this "tight coupling." I call it "fast until it's not."
Here's the rule I use now: If you can't describe why you need to split it, don't. The second you have two services that need to talk to each other, you've introduced a distributed system problem — failures, latency, data consistency. That's a real cost most advocates gloss over.
When the SIVARO dashboard hit 200 concurrent users, the monolith was fine. At 2,000, we started feeling pain. At 20,000, we split it. Not before.
python
# Monolithic approach: everything in one request-response cycle
def process_order(user_id, items):
user = get_user(user_id) # Same process
inventory = check_stock(items) # Same process
total = calculate_price(items) # Same process
charge = process_payment(user, total) # Same process
update_inventory(inventory) # Same process
send_confirmation_email(user) # Same process
return {"status": "success"}
# Simple. Fast. Boring. Perfect for 90% of startups.
Microservices Architecture
Microservices are the opposite of monoliths. Each service does one thing, has its own database, and communicates over a network (HTTP, gRPC, message queues).
When it works: Your team has 20+ engineers. Different services need different scaling characteristics. You're willing to trade operational complexity for independent deployability.
In 2023, I consulted for a logistics company that was processing 500,000 package tracking events per day. Their monolith was a mess: the tracking ingest path was competing with the billing reports for the same database connections. Every spike in tracking volume slowed down invoice generation.
We split it into six services: Ingest, Routing, Storage, Notification, Reporting, and Billing. Each service scaled independently. Ingest had 12 replicas. Billing had 2. Reporting ran on a scheduled job once per day.
Microservices architecture works because it lets you optimize each component for its specific workload. But it comes with a nasty tax: network failures become a core part of your system design.
"Is ChatGPT a distributed system?" Yes. OpenAI runs it on thousands of GPUs coordinated across multiple data centers. The inference itself is split across many workers. When you ask it a question, dozens of machines collaborate to generate a response — and if one fails mid-stream, the system has to handle that gracefully.
The worst microservices failure I saw was a company that had 47 services, each with its own Postgres instance. Their "simple profile update" endpoint required calls to 12 services in sequence. If any one failed, the user profile got corrupted. They spent six months rewriting it into a single service.
The rule: One microservice per team is a good starting point. If your team of 8 people owns 14 services, you have too many.
yaml
# docker-compose.yml for a minimal microservices setup
version: '3.8'
services:
api-gateway:
image: gateway:latest
ports:
- "8080:8080"
depends_on:
- user-service
- order-service
user-service:
image: users:latest
environment:
- DB_URL=postgres://users-db:5432/users
order-service:
image: orders:latest
environment:
- DB_URL=postgres://orders-db:5432/orders
# Each service has its own database
users-db:
image: postgres:16
orders-db:
image: postgres:16
Event-Driven Architecture
Event-driven architecture flips the model: instead of services calling services, services publish events when something happens, and other services subscribe to those events.
This is how distributed systems actually work at scale. What Are Distributed Systems? points out that most large-scale systems use asynchronous messaging to decouple producers from consumers.
When it works: You have high throughput, or you need to decouple services that don't need real-time responses. Think: user signs up → send welcome email → update CRM → add to analytics. You don't need the user to wait for all of that.
In 2024, SIVARO built a system for a media company that was ingesting 1.2 million video upload events per day. A synchronous pipeline would have crushed their API servers. Instead, we used Kafka as an event bus. Upload service published an upload.completed event. Three downstream services consumed it independently: one for transcoding, one for metadata extraction, one for content moderation.
The beauty? When the moderation service went down for three hours, the other two kept working. Events accumulated in Kafka. When moderation came back, it processed the backlog. Zero data loss.
Distributed System Architecture describes this as "temporal decoupling" — producers and consumers don't need to be alive at the same time.
The trade-off: Event-driven systems are harder to debug. You can't look at a single request trace — you need distributed tracing (OpenTelemetry, Jaeger). And you have to handle "eventual consistency" — the system won't be perfectly consistent at any instant.
I've seen teams abandon event-driven architecture because they couldn't reason about what state the system was in at any given moment. It's powerful, but it demands operational maturity.
javascript
// Publishing an event to Kafka
const { Kafka } = require('kafkajs')
const kafka = new Kafka({
clientId: 'order-service',
brokers: ['kafka-1:9092', 'kafka-2:9092', 'kafka-3:9092']
})
const producer = kafka.producer()
async function publishOrderCreated(order) {
await producer.connect()
await producer.send({
topic: 'order.events',
messages: [
{
key: order.id,
value: JSON.stringify({
type: 'OrderCreated',
orderId: order.id,
userId: order.userId,
total: order.total,
timestamp: new Date().toISOString()
})
}
]
})
await producer.disconnect()
}
// Downstream services subscribe independently
// No direct coupling between services
Layered (N-Tier) Architecture
This is the classic pattern: presentation layer (UI), business logic layer (API), data layer (database). Each layer only talks to the layer directly below it.
When it works: Most of the time. Seriously. This pattern handles 80% of business applications without drama.
Layered architecture is boring in the best way. "What did AWS stand for?" Amazon Web Services — launched in 2006 partly to monetize the infrastructure Amazon had built for its own layered e-commerce platform. AWS's own services (S3, EC2, RDS) follow layered patterns internally.
The reason layered architecture survives is separation of concerns. You can swap your frontend from React to Vue without touching the API. You can migrate your database from MySQL to Postgres without changing the UI code.
I helped a healthcare startup in 2022 that was failing because their "microservices" were actually just three logical layers deployed as separate processes with network calls between them. They had all the complexity of microservices with none of the benefits. We collapsed them into a proper layered monolith — same API boundary, same database, no network calls between layers. Their latency dropped 40% and their error rate went from 2% to 0.1%.
The trade-off: Strict layering means you can't have the UI talk directly to the database (sometimes called "skip layer" access). That's usually a good constraint. But if you're doing something unconventional — real-time collaborative editing, for instance — layered architecture might slow you down.
Distributed Architecture: 4 Types, Key Elements + Examples notes that layered architecture is the default because it maps to how teams organize: frontend team, backend team, database team. Conway's Law in action.
java
// Classic layered architecture in Java
// Controller → Service → Repository → Database
@RestController
public class OrderController {
private final OrderService orderService;
@PostMapping("/orders")
public OrderResponse createOrder(@RequestBody OrderRequest request) {
return orderService.createOrder(request); // Layer 3 calls Layer 2
}
}
@Service
public class OrderService {
private final OrderRepository orderRepository;
public OrderResponse createOrder(OrderRequest request) {
Order order = new Order(request);
order.validate(); // Business logic here
order.calculateTax(); // Layer 2 logic
return orderRepository.save(order); // Layer 2 calls Layer 1
}
}
@Repository
public class OrderRepository {
@Autowired
private JdbcTemplate jdbc;
public OrderResponse save(Order order) {
// Execute SQL - Layer 1 talks to database
jdbc.update("INSERT INTO orders ...", order.getParams());
return new OrderResponse(order);
}
}
Client-Server and Peer-to-Peer Architecture
These are the two original distributed system patterns. They're worth discussing together because they're opposites in how they handle authority.
Client-Server: One server, many clients. The server is the authority. Centralized control, easy to manage, single point of failure.
Peer-to-Peer (P2P): Every node is both client and server. No central authority. Resilient to failures, but coordination is harder — how do you find data when no one's in charge?
Distributed Systems: An Introduction explains that most modern systems are actually hybrids — they look like client-server on the outside but use P2P internally for replication and coordination.
When client-server works: Any system with a clear authority. Banking. Social media. E-commerce. The server decides what's true. Introduction to Distributed Systems calls this "the master-slave problem" — you trade availability for consistency.
When P2P works: File sharing (BitTorrent), blockchain (Bitcoin), distributed databases (Cassandra), content delivery (IPFS). The system needs to survive any single node failing.
I built a P2P-like system for a logistics client in 2023. Each warehouse node stored its own inventory data and replicated to nearby warehouses. If the central server went down, warehouses kept operating — they could query each other for stock levels. The central server was "eventually consistent" once it came back.
What Is a Distributed System? Types & Real-World Uses gives a perfect example: the Domain Name System (DNS) is a hierarchical distributed system. There's no single DNS server — it's a tree of authority, with root servers at the top and individual nameservers at the leaves.
The trade-off: Client-server creates a bottleneck and a target. P2P creates complexity in data consistency. Right now, in July 2026, most systems I see are trending back toward client-server patterns for their core business logic, with P2P reserved for specific resilience requirements.
python
# Minimal peer-to-peer node behavior
class P2PNode:
def __init__(self, node_id, known_peers):
self.node_id = node_id
self.peers = known_peers # List of other nodes
self.data_store = {}
def find_data(self, key):
# Ask local store first
if key in self.data_store:
return self.data_store[key]
# Ask peers in parallel
for peer in self.peers:
response = peer.find_data(key)
if response:
return response
return None # Data not found in the network
def replicate_data(self, key, value, ttl=3600):
# Store locally
self.data_store[key] = value
# Propagate to peers (gossip protocol)
for peer in self.peers:
peer.receive_replication(key, value, ttl)
def receive_replication(self, key, value, ttl):
if ttl > 0 and key not in self.data_store:
self.data_store[key] = value
# Continue gossiping to other peers
for peer in self.peers:
peer.receive_replication(key, value, ttl - 1)
How to Choose (and How I've Screwed It Up)
There's no universal "best" architecture. There's only the architecture that fits your constraints.
Here's a cheat sheet I use:
| Constraint | Lean toward |
|---|---|
| Team < 10 engineers | Monolith first. Split later. |
| High throughput (10K+ events/sec) | Event-driven, async |
| Strong consistency required | Monolith or layered |
| Global latency < 100ms | Edge computing + event-driven |
| Frequent independent deploys | Microservices with good CI/CD |
| Zero-downtime requirements | Event-driven with message queues |
| Single-region startup | Layered monolith, one database |
The biggest mistake I've made: Trying to predict scale. In 2020, I designed a microservices architecture for a startup that had 500 users. We spent six weeks on service boundaries, API contracts, and async workflows. By the time we shipped, they'd pivoted to a completely different business model. We'd built the wrong architecture for the wrong problem.
Now I start every project with a single rule: Build the simplest thing that could work. Then measure. Then decide if you need complexity.
Distributed Architecture: 4 Types, Key Elements + Examples echoes this: "The best architecture is the one you can ship tomorrow, not the one you can optimize for a scale you don't have yet."
FAQ: System Architecture
Q: What are the 5 types of system architecture?
A: Monolithic, Microservices, Event-Driven, Layered (N-Tier), and Client-Server/Peer-to-Peer. Each optimizes for different constraints — team size, data volume, latency, and consistency requirements.
Q: What did AWS stand for?
A: Amazon Web Services. Launched in 2006, it started as internal infrastructure for Amazon's e-commerce platform and became the dominant cloud provider. AWS's services (S3, Lambda, DynamoDB) are themselves examples of distributed system architecture patterns.
Q: Is ChatGPT a distributed system?
A: Yes. ChatGPT runs on thousands of GPUs across multiple data centers. A single query is split across many machines for inference, with coordination handled by distributed systems frameworks like Ray or custom infrastructure. If a GPU fails during generation, the system must handle it without the user noticing.
Q: Which architecture is best for a startup?
A: Monolithic layered architecture. You'll move faster, deploy simpler, and spend less time on operational complexity. Split into microservices only when you have evidence (data, not gut feel) that a single service can't handle the load.
Q: Can I combine multiple architecture types?
A: Yes. Most production systems are hybrids. Your API might be layered internally but use event-driven messaging between services. Your client-facing endpoints might be client-server, but your internal data replication might be peer-to-peer.
Q: How do I migrate from one architecture to another?
A: The Strangler Fig pattern: run both architectures in parallel, route new traffic to the new system, and gradually cut over. Never do a big-bang migration. I've seen three companies fail doing that. It doesn't work.
Q: What's the hardest architecture to operate?
A: Microservices. You trade simpler code for complex operations: service discovery, distributed tracing, circuit breakers, bulkheads, eventual consistency. If your team doesn't have strong DevOps capability, stick with monolith or layered.
Q: Is event-driven architecture always better for high throughput?
A: Usually, but not always. Event-driven systems add latency per event (serialization, network, queue storage). If your throughput is under 1,000 events/second and latency tolerance is under 10ms, a monolith with async workers might outperform an event-bus architecture.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.