An architectural style that structures an application as a collection of small services.
Microservices is an architectural style where an application is built as a collection of small, independent services. Each service handles one specific business function and can be developed, deployed, and scaled independently.
Instead of one large application doing everything, you have many small applications each doing one thing well.
Monolith: Everything in one codebase. User management, payments, notifications, products - all coupled together in a single application.
Microservices: Each function is a separate service. User service, payment service, notification service, product service - all independent.
Example: An e-commerce monolith has user accounts, shopping cart, payments, and inventory in one app. The microservices version splits these into four separate services that communicate over APIs.
Scaling: Your payment processing needs more servers but product catalog does not. With microservices, scale only what you need.
Team Independence: Different teams work on different services without stepping on each other. Frontend team, payments team, shipping team all deploy independently.
Technology Freedom: Use Node.js for one service, Python for another, Go for a third. Pick the right tool for each job.
Fault Isolation: If the recommendation service crashes, checkout still works. In a monolith, one bug can bring down everything.
Explore the complete matrix of database architectures from simple monoliths to complex distributed systems.
Services talk to each other through:
REST APIs: Service A makes HTTP requests to Service B. Simple and widely understood.
Message Queues: Services send messages (RabbitMQ, Kafka). Async communication, services do not wait for responses.
gRPC: Fast, efficient communication for internal services. More complex than REST but better performance.
Netflix: Hundreds of microservices. Recommendation service, streaming service, billing service, user service. Each scales independently based on demand.
Uber: Trip service, driver service, payment service, mapping service. Teams deploy updates without coordinating with every other team.
Amazon: Started as a monolith, migrated to microservices. Each Amazon service (recommendations, cart, checkout) is independent.
Independent Deployment: Deploy payment service without touching user service. Ship features faster.
Scalability: Scale heavily-used services, leave light services alone. Save costs.
Resilience: One service fails, others keep working. Partial outage instead of total outage.
Team Autonomy: Small teams own entire services. Clear ownership, faster decisions.
Complexity: Managing dozens of services is harder than one application. Need orchestration, monitoring, logging across services.
Network Overhead: Services communicate over network instead of function calls. Slower and less reliable.
Data Consistency: Each service has its own database. Keeping data in sync across services is tricky.
Testing: Testing interactions between services is more complex than testing one codebase.
DevOps Required: Need strong deployment pipelines, monitoring, and infrastructure automation.
Do NOT start with microservices. They add massive complexity.
Start with a monolith. When your team grows, codebase becomes unwieldy, or scaling needs differ by feature, then split into microservices.
Good Fit: Large teams, different scaling needs per feature, established product with clear boundaries.
Bad Fit: Small teams, early-stage startups, simple applications.
Instagram, Facebook, Twitter all started as monoliths. They migrated to microservices after reaching scale.
API Gateway: Single entry point for all client requests. Routes to appropriate services.
Service Discovery: Services register themselves. Other services find them dynamically.
Circuit Breaker: If a service is down, stop calling it. Fail fast instead of waiting.
Event Sourcing: Store events (user registered, order placed) and rebuild state from events.
Docker: Package each service in a container for consistent deployment.
Kubernetes: Orchestrate hundreds of containers, handle scaling and failures.
Istio: Service mesh for managing communication between services.
Prometheus/Grafana: Monitor health of all services in one dashboard.
Microservices solve organizational and scaling problems but introduce operational complexity. You trade simple codebase for complex infrastructure.
Most companies do not need microservices. They need better organized monoliths. Only migrate when growth demands it.
Microservices are not inherently better than monoliths. They solve specific problems at specific scales. Understand your needs before choosing architecture.
Start simple, add complexity only when necessary. Premature microservices waste months of development time on infrastructure instead of features.
