Short answer
A monolith deploys the application as one unit: simple to build, test and run, and usually the right start. Microservices split it into independently deployable services owned by separate teams, which helps scaling organisations and uneven workloads but adds network calls, distributed data, observability and operational complexity. Choose based on team structure and scaling pain, not trends.
Signals you may need services
- Many teams blocked on one release train.
- Components with very different scaling or reliability needs.
- Clear domain boundaries with little shared data.
Costs to acknowledge
- Distributed transactions and eventual consistency.
- Service discovery, retries, timeouts and circuit breakers.
- Tracing, logging and versioned contracts between services.
A middle path
A modular monolith enforces domain boundaries inside one deployable, making a later split far easier.
How to answer it in an interview
- Give a migration story: strangler-fig pattern, one service at a time.
- Mention Conway’s law — architecture mirrors team communication.