There are about ten "architectural styles" in every system design list. Most are variations of a handful. This post covers the 5 that actually matter — the shapes a system can take — using Swiggy as the running example and Azure as the build lens.
Think of these as the containers everything else lives inside.
The 5 at a glance
| # | Style | One-line |
|---|---|---|
| 1 | Monolith | Everything in one app, one deploy |
| 2 | Layered / N-tier | Split by technical role (UI → logic → data) |
| 3 | Microservices | Split by business capability, each deploys alone |
| 4 | Event-driven | Services react to events, not direct calls |
| 5 | Serverless / FaaS | No servers to manage, code runs on a trigger |
1. Monolith
All features in one codebase, one deployable unit.
[ Orders + Payments + Search + Delivery ] → 1 app → 1 database
| ✅ Good | ❌ Bad |
|---|---|
| Simple to build & deploy | One bug can crash everything |
| Fast at the start | Can't scale one part alone |
| Easy to test locally | Team steps on each other's code |
Swiggy in 2014: started as a monolith. The right call — you don't build 50 microservices for a startup.
Azure: one App Service.
2. Layered / N-tier
Same monolith, but sliced into horizontal layers by technical job.
Presentation (UI)
↓
Business Logic
↓
Data Access
↓
Database
| ✅ Good | ❌ Bad |
|---|---|
| Clear separation of concerns | Still deploys as one unit |
| Easy to understand | A change can ripple up/down layers |
The key point: layered ≠ microservices. It's organized internally but still one app. Most classic enterprise apps are exactly this.
Azure: App Service with clean project layers.
3. Microservices
Split by business capability. Each service = own code, own DB, own deploy.
[Order svc] [Payment svc] [Search svc] [Delivery svc]
↓DB ↓DB ↓DB ↓DB
| ✅ Good | ❌ Bad |
|---|---|
| Scale one service alone (Search at peak) | Complex — network, failures everywhere |
| One crashes ≠ all crash (fault isolation) | Hard to trace across services |
| Teams work independently | Data consistency gets tricky |
Swiggy today: microservices. Order, payment, delivery, search all separate — so dinner-peak Search scales without touching Payments.
Azure: AKS (Kubernetes) or Container Apps.
⚠️ The trap: teams jump to microservices too early. The complexity tax is real. Earn it.
4. Event-driven
Services don't call each other directly. They emit events; others react.
Order placed ──event──▶ Event Hubs ──▶ [Payment reacts]
──▶ [Restaurant reacts]
──▶ [Analytics reacts]
| ✅ Good | ❌ Bad |
|---|---|
| Fully decoupled (order doesn't know who listens) | Hard to follow the flow end-to-end |
| Add a new listener without touching order | Debugging = "where did it go?" |
| Great for spikes (buffer absorbs) | Eventual consistency by nature |
Swiggy: "Order placed" fires once → payment, restaurant, and analytics all react independently.
Azure: Event Hubs / Event Grid / Service Bus.
5. Serverless / FaaS
You write a function. The cloud runs it on a trigger. No servers to manage, scales to zero.
Trigger (HTTP / queue / timer) → Function runs → done → shuts off
| ✅ Good | ❌ Bad |
|---|---|
| Pay only when it runs | Cold starts (first call is slow) |
| Auto-scales, zero infra | Not for long-running jobs |
| Perfect for glue/small tasks | Harder to debug/monitor |
Swiggy: "send SMS on delivery," "resize a restaurant photo on upload" — small, event-triggered tasks that don't need a running server.
Azure: Azure Functions, Logic Apps.
How they actually relate (the real insight)
These aren't rivals you pick one of. Real systems layer them:
Microservices (the shape)
+ Event-driven (how they talk)
+ Serverless (for the small glue tasks)
Swiggy = all three at once. Microservices as the skeleton, event-driven as the nervous system, serverless for odd jobs.
And the evolution path almost everyone follows:
Monolith → Layered monolith → Microservices → + Event-driven → + Serverless glue
(startup) (scale) (decouple) (optimize)
The one thing to remember
Two styles both "split" the app — but for different reasons:
Layered = split inside one app → still one deploy, one crash zone.
Microservices = split into separate apps → independent deploys, isolated crash zones.
Layering organizes code. Microservices separate deployment and failure. Everything else in this list is a choice about how those separated pieces talk and run — which is the next thing worth learning.
Top comments (0)