Microservices
Microservices is an architectural style that structures an application as a collection of small, independently deployable services, each owning a single business capability and communicating over well-defined APIs.
Definition
Microservices is an architectural style that structures an application as a collection of small, independently deployable services, each owning a single business capability and communicating over well-defined APIs.
Overview
In a microservices architecture, a large application is decomposed into many small services rather than being built as one large, tightly coupled codebase. Each service is developed, tested, deployed, and scaled independently, typically owning its own database so that teams are not blocked by one another's release schedules. This is the opposite of a Monolithic Architecture, where all functionality ships as a single deployable unit. Services usually communicate over lightweight protocols such as HTTP-based REST API calls, GraphQL, or asynchronous messages, and are frequently packaged with Docker and orchestrated with Kubernetes so each one can be scaled and released on its own schedule. Because a request may now span multiple network hops, patterns like the Circuit Breaker Pattern, the Saga Pattern for distributed transactions, and an API Gateway for routing and cross-cutting concerns become essential rather than optional. The style emerged from experience at large internet companies in the 2010s that found monoliths increasingly hard to scale organizationally as headcount grew, even when the traffic itself was manageable. Netflix, Amazon, and Uber are commonly cited early adopters. Today microservices are a default option for large engineering organizations, though the operational complexity — Distributed Systems debugging, versioning, and data consistency — means many teams intentionally stay on a monolith until team size or scaling needs justify the split. Courses like MLOps & Model Deployment also apply these decomposition ideas to model-serving pipelines.
Key Concepts
- Independent deployability of each service without redeploying the whole system
- Decentralized data management, often one database per service
- Communication via lightweight APIs (REST, gRPC, GraphQL, or messaging)
- Independent scaling of individual services based on their own load
- Technology heterogeneity — each service can use a different language or stack
- Organizational alignment — teams typically own one or a few services end to end
- Resilience patterns required to handle partial failures gracefully
- Higher operational overhead: more deployments, more monitoring, more network calls