Microservices
An architectural style splitting an application into small, independently deployable services.
CurrentadvancedGuide only -- no course yet
Overview
Microservices architecture splits an application into small, independently deployable services, each owning its own data and communicating over the network (often via REST or messaging). It trades a monolith's simplicity for independent scaling and deployment, at the cost of distributed-systems complexity.
- What it is
- An architectural style where an application is composed of small, independently deployable services rather than one large codebase.
- Why it's used
- To let different teams deploy independently, scale services separately, and isolate failures -- at the cost of significant added operational complexity versus a monolith.
- Where it fits
- A system-design decision made after an application (or team) outgrows a single deployable unit -- not a default starting point for a new small project.
Core concepts
- Service boundaries
- Inter-service communication (REST, messaging)
- Independent deployability
- Data ownership per service
- Distributed failure handling
Example
The key discipline is that each service owns its own data -- order-service never reaches directly into user-service's database, it asks over the network.
// Instead of one app handling users + orders + payments,
// three small services, each with its own database:
// user-service, order-service, payment-service
// -- communicating over HTTP or a message queue.Common use cases
- Large systems with multiple independent teams
- Systems needing to scale specific components independently
Project ideas
- Sketch a monolithic app's service boundaries: which parts would become separate services, and what would each own?