Fundamentals/Basics

Monolith vs Microservices

Basics

Visual Representation

Rendering diagram...

What is it?

🏢 Think of it like building a company:

A Monolith is like a small startup where EVERYONE sits in one room — design, engineering, marketing, sales. Need to talk to someone? Just turn around. Fast, simple, but as the team grows to 500 people, the room becomes chaotic.

Microservices is like a big corporation with separate departments in different buildings — HR in Building A, Engineering in Building B, Marketing in Building C. Each department works independently, but they need to COMMUNICATE (emails, meetings, Slack) — which adds overhead.

In tech: a monolith is ONE big application where all features live in a single codebase and deploy together. Microservices splits the app into many small, independent services that communicate over the network.

💡 Simple Summary: Monolith = one big app does everything. Microservices = many small apps, each doing one thing, talking over the network.

How it works — Like you're watching it happen

Monolith (Swiggy as a monolith):

  • ONE codebase has: user login, restaurant listing, cart, payments, delivery tracking, notifications — ALL in one app.
  • ONE database stores everything: users, orders, restaurants, payments.
  • Deploy the WHOLE thing when ANY part changes. Changed a button color? Redeploy the entire app including payments.
  • If the payment code has a memory leak, the ENTIRE app crashes — including restaurant browsing and delivery tracking.

    • Microservices (Swiggy as microservices):

  • User Service handles login/signup. Restaurant Service handles menus. Order Service handles cart. Payment Service handles money. Delivery Service handles tracking.
  • Each has its OWN database. Payment service doesn't touch User service's database directly.
  • They talk via APIs (HTTP/gRPC) or message queues (Kafka).
  • Deploy Payment Service independently — doesn't affect Restaurant browsing.
  • Payment Service crashes? Users can still browse restaurants and add to cart (graceful degradation).

    • ❓ But wait — if microservices are more resilient, why doesn't everyone use them from day one?

    Because microservices are HARD. You now deal with: network failures between services, distributed transactions (how to roll back an order if payment fails?), service discovery (how does Order Service find Payment Service?), debugging across 50 services (where did the request fail?), and deploying/monitoring 50 apps instead of 1. For a team of 5 developers, this overhead is CRUSHING. Microservices are for scale — of the TEAM as much as the traffic.

    Why should you care? (Interview perspective)

  • 🎯 "Should this be a monolith or microservices?" is asked directly or implicitly in every design interview
  • Understanding when to split shows architectural maturity (not everyone should jump to microservices)
  • It leads to discussions about distributed systems challenges (the hard stuff interviewers love)
  • Shows you think about team structure and deployment, not just code

    • Key Things to Remember

  • Start monolith — Almost always start as a monolith. Split into microservices when team/codebase grows large enough that deployments become painful.
  • Conway's Law — Your system architecture mirrors your team structure. 5 teams → 5 services makes sense. 2 developers → microservices is insane.
  • Independent deployment — The #1 benefit of microservices. Change payment logic without redeploying the entire app.
  • Failure isolation — One bad service doesn't crash everything (if you handle it properly with circuit breakers).
  • Data ownership — Each microservice owns its data. No shared databases! The Order Service ASKS Payment Service for payment status — doesn't query the payments DB directly.
  • Communication overhead — In a monolith, functions call each other (nanoseconds). In microservices, they make network calls (milliseconds). 1000x slower.
  • Distributed transactions are HARD — "Create order + charge payment + notify restaurant" across 3 services. If payment fails AFTER order is created, how do you rollback? (Saga pattern)
  • Observability needed — When a request touches 15 services, debugging "why was this slow?" requires distributed tracing (Jaeger, Zipkin).
  • Service discovery — How does Service A find Service B's address? Use service registries (Consul), DNS, or Kubernetes built-in discovery.
  • The "distributed monolith" anti-pattern — If all services must deploy together or share a database, you have the WORST of both worlds. True microservices are independently deployable.

    • Real Examples You Use Daily

    🚗 Uber — Started as a monolith. As they grew to 2000+ engineers, they split into ~2000 microservices: pricing, matching, maps, payments, notifications, fraud detection — each owned by separate teams.

    📺 Netflix — 700+ microservices. Recommendation service, streaming service, user profile service, billing service. Each team owns their service end-to-end (build, deploy, monitor).

    🛒 Amazon — Famous for "two-pizza teams" — each team owns a service. Product catalog, shopping cart, payment, shipping, recommendations — all separate services communicating via APIs.

    💬 WhatsApp — Stayed largely monolithic (Erlang-based) even with 2 billion users! Proof that you don't ALWAYS need microservices. Their tech stack just scales well vertically.

    Common Mistakes in Interviews

    ❌ Immediately jumping to microservices — "For this chat app, I'd use 15 microservices." For a new system with 10K users? That's over-engineering. Start simple.

    ❌ Ignoring the data problem — Splitting services is easy. Splitting the DATABASE is the hard part. How do you handle joins across services? Discuss eventual consistency and data duplication.

    ❌ Forgetting communication latency — A function call in a monolith takes nanoseconds. A network call between services takes milliseconds. A chain of 10 service calls adds 100ms+ latency.

    ❌ Not mentioning observability — With 50 services, "the request failed" could mean any of 50 things. You need centralized logging, distributed tracing, and metrics. Mention tools: Datadog, Grafana, Jaeger.

    ❌ Calling it a binary choice — It's a spectrum! You can have a "modular monolith" (well-separated modules inside one deployment) or start with 3-5 "macro-services" instead of jumping to 50 microservices.

    🎯 Interview One-Liner

    "I'd start with a well-structured monolith for development velocity, then extract services at natural boundaries — where teams need independent deployment cycles or when a component has distinctly different scaling requirements — ensuring each service owns its data and communicates via well-defined APIs."

    Interview Q&A

    Q: When should you break a monolith into microservices?

    When you see these signs: (1) Deployments are slow/risky because everything is coupled, (2) Different teams step on each other's code constantly, (3) One component needs to scale differently (e.g., image processing needs GPUs, but user auth doesn't), (4) A bug in one feature crashes unrelated features. Usually this happens around 20-50 engineers.

    Q: What's the hardest part about microservices?

    Distributed data management. In a monolith, you have one database with transactions. In microservices, data is split across services. An "order" involves data from User Service + Product Service + Payment Service + Inventory Service. Keeping all this consistent without a shared database requires patterns like Sagas, eventual consistency, and event-driven architecture. It's genuinely hard.

    Q: How do microservices communicate?

    Two patterns: (1) Synchronous — direct HTTP/gRPC calls. Fast, simple, but creates tight coupling and cascading failures. (2) Asynchronous — message queues (Kafka, RabbitMQ). Services publish events ("order created"), others consume them. Decoupled, resilient, but harder to debug and eventually consistent. Most systems use BOTH — sync for reads, async for writes/notifications.

    Q: What's a Saga pattern?

    It's how you do "transactions" across microservices. Instead of one big DB transaction, it's a sequence of local transactions with compensating actions. Example: (1) Order Service creates order, (2) Payment Service charges card, (3) If payment fails → Order Service cancels order (compensating action). Either choreography (services listen to events) or orchestration (a coordinator directs the steps).

    Q: Monolith vs microservices for a startup?

    Monolith — 100%. A startup's priority is speed-to-market, not architectural purity. With 3-5 developers, microservices add enormous operational overhead (DevOps, monitoring, debugging distributed systems) without proportional benefit. Build a clean, modular monolith. If you succeed and grow to 50+ engineers, THEN extract services where it hurts most. Instagram was a monolith when it hit 100M users.

    Quick Quiz

    1/5

    A startup with 4 engineers wants to build a food delivery app. What architecture should they start with?

    Horizontal vs Vertical ScalingSingle Point of Failure (SPOF)