Microservices interview questions

What a strong answer covers

• Define microservices as small, independent, loosely coupled services focused on a single business capability.
• Explain that each microservice runs in its own process and communicates via lightweight mechanisms (e.g., APIs).
• Contrast with monoliths: a single, tightly coupled application deployed as one unit.
• Highlight key differences: deployment (independent vs. single), scalability (individual vs. whole), technology stack (polyglot vs. uniform).

Where people lose the point

• ×Failing to mention independent deployability as a core characteristic.
• ×Confusing microservices with simply breaking a monolith into modules without independent deployment.

What a strong answer covers

• Define bounded context as a central pattern in Domain-Driven Design (DDD) that delineates a specific domain model.
• Explain that within a bounded context, terms and concepts have a specific, unambiguous meaning.
• Relate it to microservices: each microservice typically aligns with a single bounded context.
• Discuss how it helps in defining clear service boundaries and preventing ambiguity across the system.

Where people lose the point

• ×Describing it as merely a 'module' or 'component' without emphasizing the domain model and ubiquitous language aspect.
• ×Failing to connect it to the idea of clear service boundaries.

What a strong answer covers

• Define independent deployability as the ability to deploy, update, or roll back a single microservice without affecting other services.
• Explain that this is a core characteristic that distinguishes microservices from monolithic architectures.
• Discuss its importance for agility: faster release cycles, reduced risk of deployment failures impacting the entire system.
• Mention how it enables teams to work autonomously on their services.

Where people lose the point

• ×Not clearly stating that other services are unaffected by a single service's deployment.
• ×Focusing only on speed without mentioning reduced risk or team autonomy.

What a strong answer covers

• Synchronous communication: client sends request, waits for immediate response (e.g., REST, gRPC).
• Asynchronous communication: client sends message/event, doesn't wait for immediate response; processing happens later (e.g., message queues, event streams).
• Highlight key differences: coupling (tight vs. loose), blocking (yes vs. no), immediate feedback (yes vs. no).
• Provide examples for each type of communication.

Where people lose the point

• ×Confusing the concepts or misidentifying common protocols for each type.
• ×Failing to mention the impact on coupling or blocking behavior.

What a strong answer covers

• Benefits: improved scalability (individual services), enhanced agility (faster development/deployment), fault isolation, technology diversity, easier maintenance of smaller codebases.
• Drawbacks: increased operational complexity (deployment, monitoring, debugging), distributed data management challenges, inter-service communication overhead, higher initial setup cost.
• Emphasize that it's a trade-off and not a universal solution.
• Mention the need for a strong DevOps culture and automation.

Where people lose the point

• ×Only listing benefits or drawbacks without discussing both sides comprehensively.
• ×Failing to acknowledge the increased complexity as a major drawback.

What a strong answer covers

• Microservices are suitable for large, complex applications requiring high scalability, rapid development by multiple independent teams, and fault tolerance.
• Monoliths are often better for smaller, simpler applications, startups with limited resources, or when development speed is prioritized over long-term scalability/flexibility.
• Consider team size and organizational structure: microservices align well with Conway's Law for larger, autonomous teams.
• Emphasize that the decision depends on business needs, team capabilities, and operational maturity.

Where people lose the point

• ×Suggesting microservices are always the best choice regardless of context.
• ×Not considering team size, operational overhead, or project complexity in the recommendation.

What a strong answer covers

• Define 'database per service' as each microservice owning its private database, not shared with other services.
• Explain its benefits: loose coupling, independent evolution of data schemas, polyglot persistence (choosing best database for each service).
• Discuss implications/challenges: distributed data consistency, complex cross-service queries, need for eventual consistency and distributed transaction patterns (e.g., Saga).
• Mention that direct database access from other services is forbidden; communication must be via service APIs.

Where people lose the point

• ×Suggesting that services can directly query other services' databases.
• ×Not addressing the challenges of data consistency or cross-service querying.

What a strong answer covers

• Define API Gateway as a single entry point for all client requests to the microservices system.
• Explain its role in routing requests to the appropriate microservice.
• List problems it solves: reduces client-side complexity (single endpoint), handles cross-cutting concerns (authentication, authorization, rate limiting, caching, logging).
• Mention how it can perform request aggregation and protocol translation.

Where people lose the point

• ×Confusing it with a load balancer or service mesh without explaining its higher-level responsibilities.
• ×Failing to mention its role in handling cross-cutting concerns.

What a strong answer covers

• Define eventual consistency: a consistency model where data might be inconsistent for a period, but will eventually become consistent across all replicas/services.
• Explain that it's a trade-off for availability and partition tolerance (CAP theorem).
• Discuss why it's accepted in microservices: 'database per service' makes strong consistency across services difficult and costly.
• Mention that many business processes can tolerate temporary inconsistencies, and it enables higher scalability and resilience.

Where people lose the point

• ×Implying that data is always consistent or that inconsistencies are never resolved.
• ×Not connecting it to the 'database per service' pattern or the CAP theorem.

What a strong answer covers

• Explain that distributed systems are inherently complex, making traditional debugging difficult.
• Define the three pillars: Logging (detailed events), Metrics (numerical measurements), Tracing (request flow across services).
• Discuss how observability helps: quickly identify issues, understand system behavior, monitor performance, debug distributed transactions.
• Emphasize that without it, troubleshooting becomes a 'needle in a haystack' problem.

Where people lose the point

• ×Only mentioning one or two pillars of observability.
• ×Failing to explain *why* it's more critical in microservices than in monoliths.

What a strong answer covers

• Explain that traditional ACID transactions across multiple services are generally avoided due to tight coupling and performance overhead.
• Introduce the concept of eventual consistency as the primary approach.
• Describe the Saga pattern: a sequence of local transactions, where each transaction updates data within a single service and publishes an event.
• Explain how compensating transactions are used in a Saga to undo previous steps if a later step fails, ensuring overall consistency.
• Mention two types of Saga: Choreography (event-driven) and Orchestration (central coordinator).

Where people lose the point

• ×Suggesting that two-phase commit (2PC) is a common or recommended solution for microservices.
• ×Not explaining how compensating transactions work in the Saga pattern.

What a strong answer covers

• Define service discovery: the process by which client services find the network location of other services.
• Explain why it's needed: dynamic nature of microservices (scaling, failures, deployments) means service instances' locations change frequently.
• Describe Client-Side Discovery: client queries a service registry (e.g., Eureka, Consul) to get service locations and then makes direct calls.
• Describe Server-Side Discovery: client makes requests to a router/load balancer (e.g., Nginx, Kubernetes Service) which queries the registry and forwards the request.
• Discuss the trade-offs of each approach (complexity, network hops).

Where people lose the point

• ×Confusing service discovery with DNS or static IP addresses.
• ×Not clearly differentiating between client-side and server-side approaches.

What a strong answer covers

• Explain that resilience is crucial in distributed systems to prevent cascading failures and maintain availability.
• Circuit Breaker: prevents repeated calls to a failing service, allowing it to recover and preventing resource exhaustion.
• Bulkhead: isolates resources (e.g., thread pools, connection pools) for different components/services to prevent one failing component from consuming all resources.
• Retry: automatically re-attempts failed operations, often with exponential backoff, for transient failures.
• Mention other patterns like Timeout, Fallback, Rate Limiting, and their collective goal of graceful degradation.

Where people lose the point

• ×Only listing patterns without explaining their purpose or how they work.
• ×Not connecting the patterns to the overall goal of preventing cascading failures.

What a strong answer covers

• Start with identifying clear business capabilities or bounded contexts within the monolith.
• Prioritize 'strangler fig' pattern: gradually extract services, leaving the monolith to shrink over time, rather than a 'big bang' rewrite.
• Identify low-risk, high-value services to extract first (e.g., services with clear boundaries, high change frequency, or independent scaling needs).
• Address data migration: either duplicate data, use event-driven synchronization, or migrate data along with the service.
• Establish robust communication (API Gateway, message queues) and observability for the new services.

Where people lose the point

• ×Suggesting a 'big bang' rewrite as the primary strategy.
• ×Not considering data migration or the need for an API Gateway during the transition.

What a strong answer covers

• Explain the need for API versioning to allow services to evolve without breaking existing clients.
• Discuss common versioning strategies: URI versioning (e.g., /v1/users), Custom Header versioning (e.g., X-API-Version), Query Parameter versioning (e.g., /users?version=1).
• Explain the trade-offs of each approach (readability, caching, client complexity).
• Emphasize backward compatibility as a primary goal and the importance of clear documentation.
• Mention strategies for deprecation and eventual removal of old versions.

Where people lose the point

• ×Not discussing the trade-offs of different versioning strategies.
• ×Failing to mention the importance of backward compatibility or deprecation.

What a strong answer covers

• Authentication and Authorization: Centralized identity provider (e.g., OAuth2, OpenID Connect) for user authentication, token-based authorization (JWT) for inter-service communication.
• Secure Communication: Use TLS/SSL for all inter-service communication (mTLS) and external API calls.
• API Gateway Security: Implement rate limiting, input validation, and WAF at the API Gateway.
• Data Security: Encrypt data at rest and in transit, implement strict access controls for databases.
• Vulnerability Management: Regular security scanning, dependency management, and patching for each service.

Where people lose the point

• ×Only focusing on external client security and neglecting inter-service communication security.
• ×Not mentioning the role of an API Gateway in centralizing some security concerns.

What a strong answer covers

• Unit Testing: Standard practice for individual components within a service.
• Integration Testing: Test interactions between a service and its immediate dependencies (e.g., database, external API), often using mocks or test doubles.
• Contract Testing: Ensure services adhere to agreed-upon API contracts (e.g., Pact), preventing breaking changes between consumer and provider.
• End-to-End Testing: Test critical business flows across multiple services, but keep these minimal due to complexity and flakiness.
• Consumer-Driven Contracts (CDC) as a key strategy to manage integration complexity.

Where people lose the point

• ×Suggesting extensive end-to-end testing as the primary integration strategy.
• ×Not mentioning contract testing or consumer-driven contracts as a way to manage integration complexity.

What a strong answer covers

• Define DDD as an approach to software development that focuses on modeling software to match a domain according to input from domain experts.
• Explain key DDD concepts: Bounded Context, Ubiquitous Language, Aggregates, Entities, Value Objects.
• Connect DDD to microservices: each microservice typically encapsulates a single Bounded Context.
• Discuss how DDD helps define clear service boundaries, reduce coupling, and ensure services are aligned with business capabilities.
• Mention that a well-designed microservice architecture often emerges from applying DDD principles.

Where people lose the point

• ×Treating DDD as merely a way to name services rather than a comprehensive design philosophy.
• ×Failing to explain how Bounded Contexts directly map to microservice boundaries.