Microservices are a software architecture in which an application is split into small independent services, each responsible for a specific business function and deployable separately from the others.
Instead of one big program (a monolith), you get for instance one service for payments, one for the catalog, one for notifications. Each often has its own database and communicates with the others through APIs or messages. A team can change and deploy its service without waiting for the others.
The benefits: more autonomous teams, targeted scaling of the busiest parts, technical choices suited to each service. The cost is real:
- a distributed system, harder to test and debug
- a strong need for observability, automation and tools like Docker and Kubernetes
- distributed data that must be kept consistent
Many teams go back to a modular monolith when the size of the organization does not justify that cost.
Why it matters when hiring
Having worked on microservices does not prove one knows how to design them. Ask candidates how they split the services, how they handle a cascading failure or shared data, and when they would advise against this architecture. A good architect knows how to say no to microservices. For a young team, a profile who pushes them from day one is often a warning sign.