Microservices is an architectural pattern where an application is composed of small, independent services that communicate over a network. Each service owns a specific business capability, runs in its own process, and can be developed, deployed, and scaled independently. This contrasts with a monolith, where all functionality lives in a single deployable unit.
How It Works
In a microservices architecture, each service has its own database, its own codebase (or section of a monorepo), and its own deployment pipeline. Services communicate through APIs (typically REST or gRPC) or asynchronous messaging (event buses like Kafka or RabbitMQ). An e-commerce platform might split into services for user accounts, product catalog, inventory, orders, payments, and notifications.
Each service is small enough for one team to own entirely. Teams choose their own technology stacks, deploy on their own schedules, and scale their services based on individual load patterns. The payment service can scale independently during a sale without over-provisioning the notification service.
Why It Matters
Microservices solve organizational scaling. When a monolith has 200 developers committing to the same codebase, merge conflicts, deployment coordination, and blast radius of failures become paralyzing. Independent services let teams move at their own pace. Amazon, Netflix, and Uber all migrated to microservices to support their engineering growth.
Individual services are also easier to reason about. A 5,000-line service is simpler to understand, test, and debug than a 500,000-line monolith.
In Practice
Netflix runs over 1,000 microservices. Their recommendation engine, video encoding, user profiles, and billing all operate independently. If the recommendation service fails, users still watch content; they just see a generic "Popular" list instead of personalized suggestions. This fault isolation prevents cascading failures.
Common Mistakes
Microservices introduce significant operational complexity: distributed tracing, network failures, data consistency across services, and service discovery all demand mature tooling and practices. Most startups should begin with a well-structured monolith and extract services only when specific scaling or organizational pain points emerge. Premature microservices adoption is a common and expensive mistake.