Microservices

Microservices is a software architecture style where an application is structured as a collection of small, independent services that communicate over a network, each responsible for a specific business capability and deployable independently.

Category: General (also: Software Engineering, Architecture)

Author: Atomic Glue Technical Team

## Definition

Microservices (or microservice architecture) is an architectural approach that structures an application as a set of loosely coupled, independently deployable services. Each service focuses on a specific business domain and can be developed, deployed, and scaled independently. Services communicate through well-defined APIs, typically via HTTP/REST or messaging queues. This contrasts with monolithic architecture, where all functionality is built as a single, interconnected unit. Microservices emerged from the principles of domain-driven design (DDD), continuous delivery, and the need for organizations to scale development teams independently. The approach was popularized by companies like Netflix, Amazon, and Spotify, who needed to scale both their software and their engineering organizations.

## Microservices vs Monolith

The core difference is how you divide the application: * **Monolith:** All code is in one application. Simple to develop, test, and deploy initially. Becomes difficult to scale as the codebase grows. A single bug can bring down the entire application. * **Microservices:** The application is split into many small services. Each can be developed in different languages, scaled independently, and deployed without affecting others. A bug in one service affects only that service. The tradeoff is complexity. A monolith is simple to start but hard to scale. Microservices are complex to start but enable independent scaling and team autonomy. The rule of thumb: start with a monolith. Split into microservices only when the monolith's complexity justifies the overhead.

## Key Characteristics of Microservices

Well-designed microservices share these traits: * **Single Responsibility:** Each service owns one business capability (e.g., payment processing, user management, inventory). * **Independent Deployment:** Each service can be deployed without coordinating deployments of other services. * **Decentralized Data:** Each service manages its own database. No shared database across services. * **Resilience:** Failure in one service should not cascade. Implement circuit breakers, bulkheads, and retries. * **Observability:** With many services, centralized logging, metrics, and tracing are essential. * **API-First:** Services communicate through well-defined, versioned APIs.

## When to Use Microservices

Microservices are not a default choice. They are a solution to specific problems: independent team velocity, scaling specific parts of the system independently, polyglot technology stacks, and fault isolation. Consider microservices when: your engineering team is multiple squads (Conway's Law says architecture mirrors organizational structure), your monolith has become a "big ball of mud" with tangled dependencies, different parts of your system have different scaling requirements, or you need to release updates to specific components frequently. Do not choose microservices for early-stage products, small teams, or simple applications. The operational overhead of managing multiple services, databases, and deployment pipelines is significant.

## Common questions

Q: Are microservices faster than a monolith?

A: No. Microservices introduce network latency, serialization overhead, and distributed system complexity. They are not faster; they are more scalable and allow team independence.

Q: How big should a microservice be?

A: Small enough to be owned by a single team, focused on one business capability. There is no line count rule. The service should be replaceable in a reasonable time frame.

Q: Do microservices require containers?

A: Not strictly, but practically yes. Containers (Docker) provide consistent runtime environments, isolation, and efficient deployment. Kubernetes has become the standard orchestrator for microservices.

## Key takeaways

• Microservices structure applications as independent, deployable services focused on single business capabilities.
• They enable independent team velocity and scaling but introduce significant operational complexity.
• Start with a monolith; extract microservices only when the monolith's complexity demands it.
• Key enablers: containers, CI/CD, API gateways, and observability infrastructure.

## Related entries

• [SaaS / IaaS / PaaS](atomicglue.co/glossary/saas)
• [Open Source](atomicglue.co/glossary/open-source)
• [Technical Debt](atomicglue.co/glossary/technical-debt)

Last updated July 2025. Permalink: atomicglue.co/glossary/microservices