USA
Canada
UK
Europe
Australia
Singapore
Japan
IndiaQ1. What are microservices and what are their trade-offs vs a monolith?
Short answer: Independently deployable services split by business capability; flexibility at the cost of complexity.
Strong answer: Microservices decompose an app into small, independently deployable services owned by teams, enabling independent scaling, deployment and tech choices. The trade-off is distributed-systems complexity: network calls, data consistency, observability and operational overhead. Start with a modular monolith and split only when the benefits outweigh that complexity.
Likely follow-up: When is a monolith the better choice?
What the interviewer is checking: Architectural judgment, not hype.
Common mistake: Jumping to microservices prematurely for a small app.
Q2. How do you handle data consistency across microservices?
Short answer: Each service owns its data; use eventual consistency, sagas and events instead of distributed transactions.
Strong answer: Each service owns its database, so you avoid distributed ACID transactions. Use the saga pattern (choreography or orchestration) with compensating actions for multi-service workflows, and events for eventual consistency. Design for idempotency and handle partial failures explicitly. Two-phase commit across services is usually an anti-pattern.
Likely follow-up: What is a compensating transaction in a saga?
What the interviewer is checking: Distributed-data understanding.
Common mistake: Trying to use a shared database or 2PC across services.
Q3. How do services communicate, and when do you choose sync vs async?
Short answer: Sync (REST/gRPC) for request/response; async (events/messaging) for decoupling and resilience.
Strong answer: Synchronous REST/gRPC suits immediate request/response but couples availability. Asynchronous messaging/events (Kafka, queues) decouples services, absorbs spikes and improves resilience, at the cost of eventual consistency and added complexity. Many systems mix both; prefer async for cross-service workflows and events.
Likely follow-up: What happens to a synchronous chain if one service is slow?
What the interviewer is checking: Communication-pattern judgment.
Common mistake: Long synchronous call chains that cascade failures.
Q4. How do you make microservices resilient?
Short answer: Timeouts, retries with backoff, circuit breakers, bulkheads and fallbacks.
Strong answer: Protect against downstream failure with sensible timeouts, retries with exponential backoff and jitter (only for idempotent calls), circuit breakers to stop hammering a failing service, bulkheads to isolate resources, and graceful fallbacks. Without these, one slow dependency can cascade into a full outage.
Likely follow-up: Why can naive retries make an outage worse?
What the interviewer is checking: Resilience-pattern knowledge.
Common mistake: Retrying aggressively with no backoff or circuit breaker.
Q5. What is an API gateway and why use one?
Short answer: A single entry point handling routing, auth, rate limiting and cross-cutting concerns.
Strong answer: An API gateway is the front door to microservices, handling routing, authentication, rate limiting, TLS termination and request aggregation — so clients don’t call services directly and cross-cutting concerns live in one place. Combined with service discovery, it decouples clients from internal topology.
Likely follow-up: What is the risk of putting too much logic in the gateway?
What the interviewer is checking: Edge-architecture understanding.
Common mistake: Exposing every service directly with duplicated auth logic.
Q6. How do you achieve observability across microservices?
Short answer: Correlated logs, metrics and distributed tracing tied together by request/trace IDs.
Strong answer: Instrument services to emit structured logs, metrics and distributed traces (OpenTelemetry), propagating a trace/correlation ID across calls so you can follow a request end-to-end. Centralize in tracing/metrics backends. Without distributed tracing, debugging a slow request across many services is nearly impossible.
Likely follow-up: How does a trace ID help debug a slow cross-service request?
What the interviewer is checking: Distributed observability.
Common mistake: Per-service logs with no correlation across the call chain.
Q7. How do you handle service discovery and configuration?
Short answer: A registry (or platform DNS) for discovery; externalized, centralized configuration.
Strong answer: Services find each other via a registry (Consul/Eureka) or platform DNS (Kubernetes Services), so instances can scale and move. Configuration is externalized (config server, ConfigMaps/Secrets, environment) rather than baked in, enabling per-environment settings and safe rotation. Both decouple deployment topology from code.
Likely follow-up: How does Kubernetes provide service discovery out of the box?
What the interviewer is checking: Operational microservices knowledge.
Common mistake: Hardcoding service hostnames and config in the app.