What is a microservices architecture?
Why Interviewers Ask This
This question tests conceptual clarity. Interviewers want to hear a precise, confident definition before moving to more complex System Design topics. It also reveals how well you can explain technical ideas to non-experts.
Answer
Microservices architecture structures an application as a collection of small, independently deployable services, each responsible for a single business capability with its own data store. Each service runs in its own process and communicates via lightweight APIs (HTTP/REST, gRPC) or message queues. Key characteristics: single responsibility (each service does one thing well); independent deployment (deploy one service without touching others); independent scaling (scale the payment service 10x without scaling user service); technology diversity (each service can use different language/database); decentralized data management (each service owns its data). Benefits: independent deployments, faster release cycles, isolated failures (one service crash doesn't bring down everything), team autonomy (each team owns their service), granular scaling. Challenges: distributed system complexity; network latency between services; distributed transactions (no ACID across services — use Saga pattern); service discovery; operational overhead (many services to monitor, deploy, version); testing complexity (integration tests span multiple services); data consistency. Communication patterns: synchronous (REST, gRPC — direct request/response); asynchronous (Kafka, RabbitMQ — event-driven, decoupled). When to use: large teams, complex domains, different scaling needs per component. When NOT to use: small teams, simple applications, early stage startups — start with a monolith and extract microservices as complexity grows.
Common Mistake
Rushing to answer is a common mistake. Take two seconds to structure your response: definition → example → trade-off. This structure makes complex System Design answers easy to follow.