# Monolith vs Microservices — System Design: Architecture, Scale and Trade-offs

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

> Weigh a monolith against microservices, understand the operational cost of splitting and know when to extract services.

## 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.