Microservices architecture is a structural approach to software development where an application is built as a collection of small, independently deployable services, each responsible for a specific business capability. Unlike a monolithic system where all functionality lives inside a single deployable unit, a microservices system distributes that functionality across multiple processes that communicate over well-defined interfaces.
Each service in a microservices system owns its own logic, data, and deployment lifecycle. This separation means a team working on the billing service can release updates without coordinating with the team working on the user profile service. That independence is the defining characteristic of the architectural style, and it is what makes microservices attractive for organizations that want to accelerate delivery.
The term was popularized in the software community around 2011 and 2012, though many of its underlying ideas trace back to earlier work on service-oriented architecture and Unix-style design philosophy. The core Unix idea that programs should do one thing well and communicate through standard interfaces maps directly to how well-designed microservices behave.
A common misconception is that microservices simply means small services. Size is a secondary concern. The primary concern is that each service is organized around a business capability, can be deployed independently, and communicates through technology-agnostic interfaces. A service might have ten lines of logic or ten thousand, depending on the scope of the capability it encapsulates.
Three properties consistently appear in well-architected microservices systems. First, services are independently deployable, meaning a change to one service does not require redeployment of any other. Second, services are loosely coupled, meaning they do not share databases, internal code libraries, or tightly synchronized release schedules. Third, services are highly cohesive, meaning each service contains everything it needs to fulfill its specific responsibility without delegating core logic to another service.
Understanding these three properties helps teams distinguish genuine microservices systems from distributed monoliths, which are systems that have been split into separate processes but still share databases or require coordinated deployments. A distributed monolith carries the operational complexity of microservices without delivering the deployment independence that makes microservices valuable.
Consider a mid-size e-commerce platform that started as a monolithic application. The product catalog, order management, customer accounts, and payment processing all ran inside a single codebase. As the team grew to thirty developers, deployments became risky because every release contained changes from multiple teams, and a bug in the payment module could block a catalog update. The team decomposed the system into four independently deployable services, each owned by a dedicated team. Afterward, the catalog team could release product search improvements three times per week without waiting for the payment team to finish their quarterly compliance update.
- Microservices architecture builds applications as collections of small, independently deployable services organized around business capabilities.
- The key properties are independent deployability, loose coupling, and high cohesion.
- Size is less important than organizational alignment and deployment independence.
- A distributed monolith shares databases or requires coordinated releases and does not deliver the benefits of true microservices.