# Monolith vs Microservices — System Design

Source: https://www.geekswithgeeks.com/en/system-design/sd-monolith-microservices

> Choosing between one deployable and many, and living with the tradeoff.

## What each one is

A **monolith** ships all features as one deployable unit sharing a codebase, process, and database. **Microservices** split the system into independently deployable services, each owning its own data.

## Why teams split

Microservices let teams **deploy independently**, scale hot services alone, and use different tech per service. The cost is network calls where function calls used to be, and operational complexity — service discovery, distributed tracing, versioned contracts.

## One kitchen vs a food court

A monolith is one big kitchen — efficient when small, chaotic when every chef needs the same stove. Microservices are a food court: each stall (service) has its own equipment and can be renovated without closing the others, but you now need signage and shared payment (contracts, gateways) to feel like one restaurant.

## Start monolith, split with pain

Most successful systems start as a well-modularized monolith and extract services only when a specific team or scale bottleneck demands it. Splitting too early adds distributed-systems cost before you've earned the benefit.