Top 50 Microservices Interview Questions & Answers India 2026

Monolithic: All components in a single deployable unit. Simple to develop and debug initially. As the codebase grows: deployment is risky (all-or-nothing), scaling is inefficient (scale the whole app instead of just the bottleneck), and tech choices are locked in.

Microservices: Application split into small, independently deployable services, each with its own database. Services communicate via REST APIs, gRPC, or message queues (Kafka).

Advantages of microservices: Independent scaling, independent deployment, tech stack flexibility, fault isolation.
Disadvantages: Distributed systems complexity (network failures, latency), eventual consistency challenges, operational overhead (many services to monitor and deploy).

An API Gateway is the single entry point for all client requests in a microservices system. It routes requests to the appropriate service.

Key responsibilities:
• Request routing (route /orders to Order Service, /payments to Payment Service)
• Authentication & Authorization (verify JWT tokens before passing to services)
• Rate limiting (prevent abuse)
• SSL termination
• Request/response transformation
• Load balancing
• Circuit breaker / retry logic

Popular implementations: AWS API Gateway, Kong, Nginx, Netflix Zuul, Spring Cloud Gateway.

Service discovery allows services to find each other without hardcoded IP addresses (which change as services are deployed, scaled, or fail).

Client-side discovery: The client queries a service registry (e.g., Eureka) to get available instances, then load-balances itself. Example: Netflix Ribbon + Eureka.

Server-side discovery: The client sends requests to a load balancer / API gateway, which queries the service registry and forwards the request. The client doesn't know about discovery. Example: AWS ALB + ECS service discovery.

Service registries: Netflix Eureka, Consul, etcd, AWS Cloud Map.

Synchronous (REST, gRPC): The caller waits for a response. Simple, easy to implement, easier to debug. Problem: tight coupling — if the downstream service is down or slow, the caller is blocked. Cascading failures are a risk.

Asynchronous (Kafka, RabbitMQ, SQS): The caller sends a message and continues — response comes later (or not at all). Decouples services. The producer doesn't need to know if/when the consumer processes the message. Better for high-throughput, event-driven workflows (order placed → multiple consumers: payment, inventory, notification).

Rule of thumb: Use sync for user-facing, real-time requests. Use async for background processing, non-critical notifications, and event propagation.

The circuit breaker prevents a failing service from being called repeatedly, causing cascading failures and resource exhaustion.

Three states:
1. Closed (Normal): All requests pass through. Failures are tracked.
2. Open (Tripped): Failure rate exceeds threshold → circuit opens. All requests immediately return an error (fail fast) without calling the service — giving it time to recover.
3. Half-Open (Testing): After a timeout, a limited number of test requests are allowed through. If successful → back to Closed. If failing → back to Open.

Java implementation: Resilience4j (preferred, lightweight). Hystrix was popular but is deprecated. Configure with Spring Boot via @CircuitBreaker annotation.

The Saga pattern manages distributed transactions across multiple microservices by breaking them into a sequence of local transactions, each with a compensating transaction for rollback.

Example — Order flow: Place Order → Reserve Inventory → Process Payment → Schedule Delivery. If Payment fails: Saga triggers compensating transactions: Cancel Delivery Reservation → Release Inventory → Cancel Order.

Two styles:
• Choreography: Each service publishes an event after its step; other services listen and react. Decentralized, no single point of failure. Hard to trace.
• Orchestration: A central "Saga Orchestrator" service tells each service what to do. Easier to understand and debug. Single point of control (and failure).

CQRS (Command Query Responsibility Segregation) separates read (Query) and write (Command) operations into different models — often different services or databases.

Why: In a system with very different read and write loads, a single model is a compromise. CQRS lets you optimize each side independently. The write model enforces business rules and consistency. The read model is denormalized for fast queries (e.g., Elasticsearch for product search, Redis for dashboards).

Used with Event Sourcing: Writes generate events stored in an event log. Read models are built by replaying events. The system is always consistent at some point in time (eventual consistency).

Instead of storing the current state, Event Sourcing stores the sequence of events that led to the current state. The current state is derived by replaying events.

Example: Instead of a bank account table with a "balance" column, store events: AccountCreated(₹0), Deposited(₹5000), Withdrawn(₹1000). Balance = replay all events. Complete audit trail. Can reconstruct state at any point in time.

Trade-offs: Great for audit, debugging, temporal queries. Complex to implement. Query performance requires snapshots + projections (read models). Changing event schemas is hard.

The "Database per Service" pattern gives each microservice its own database (or schema). This ensures:
1. Loose coupling: Services cannot directly access each other's data — all access goes through the service's API. Schema changes in one service don't break others.
2. Independent scaling: Scale the database of a high-load service independently (e.g., Order Service might use Cassandra for high write volume, while User Service uses PostgreSQL).
3. Technology flexibility: Each service can use the best database for its needs.

Trade-off: No cross-service JOINs. Maintaining consistency across services requires patterns like Saga and event-driven sync.

A service mesh manages service-to-service (east-west) communication within the cluster. It handles: mutual TLS (mTLS), retry logic, timeouts, circuit breaking, load balancing, and distributed tracing — all transparently via sidecar proxies (e.g., Envoy) injected into each pod.

An API gateway manages external (north-south) traffic — from clients/browsers to the cluster. Handles auth, rate limiting, routing.

Popular service meshes: Istio (Envoy-based, feature-rich), Linkerd (lightweight), AWS App Mesh. Both API gateway and service mesh are often used together.

Kafka is a distributed event streaming platform — a highly scalable, fault-tolerant message queue designed for high-throughput, ordered, persistent streams.

Topic: A named log of events (like a database table for messages). Producers write to topics; consumers read from topics.
Partition: A topic is split into partitions for parallelism and horizontal scaling. Each partition is an ordered, immutable log. Messages within a partition are delivered in order.
Consumer Group: A group of consumers that together consume all partitions of a topic. Each partition is assigned to exactly one consumer in a group — enabling parallel processing. Multiple consumer groups can independently read the same topic (broadcast).

Use Kafka for high-throughput event streams, audit logs, event sourcing. Use RabbitMQ for task queues with complex routing, when you need message priorities or dead-letter queues (DLQ) with immediate expiry.

At-most-once: Messages may be lost, but never duplicated. Consumer commits offset before processing. If it crashes after commit but before processing, the message is lost. Use when some loss is acceptable (metrics, analytics).

At-least-once: Messages are never lost, but may be duplicated. Consumer commits offset after processing. If it crashes after processing but before committing, the message is reprocessed. Requires idempotent consumers.

Exactly-once: No loss and no duplicates. Hardest to achieve. Kafka supports this via idempotent producers (dedup by sequence number) + transactional API. More overhead.

Docker is a containerization platform that packages an application and all its dependencies into a lightweight, portable container.

Container: Shares the host OS kernel. Starts in milliseconds. Lightweight (MBs). Process-level isolation.
Virtual Machine: Has its own full OS. Boots in minutes. Heavy (GBs). Hardware-level isolation via hypervisor (VMware, VirtualBox, KVM).

Docker advantage: "It works on my machine" is solved — the container contains everything the app needs. Consistent across dev, staging, and production.

Kubernetes (K8s) is a container orchestration platform — it manages the deployment, scaling, and operation of containerized applications across a cluster.

Problems it solves:
• Auto-scaling: Horizontal Pod Autoscaler scales pods based on CPU/memory.
• Self-healing: Restarts crashed containers, replaces failed nodes.
• Service discovery & load balancing: Built-in via Kubernetes Services.
• Rolling deployments: Zero-downtime updates (rolling update strategy).
• Config management: ConfigMaps and Secrets decouple config from code.

Key concepts: Pod (one or more containers), Deployment (manages pod replicas), Service (stable network endpoint), Ingress (external routing).

Liveness probe: Checks if the container is alive. If it fails, Kubernetes restarts the container. Use for detecting deadlocks or infinite loops where the app is running but stuck.

Readiness probe: Checks if the container is ready to serve traffic. If it fails, the pod is removed from the Service's load balancer (traffic stops routing to it) — but the container is NOT restarted. Use during startup when the app needs time to warm up (e.g., load caches), or during overload.

Startup probe: For slow-starting containers — delays liveness probe checks until the startup probe succeeds. Prevents premature restarts during long initialization.

In microservices, a single user request may span dozens of services. Distributed tracing allows you to track the end-to-end journey of a request, measuring latency and pinpointing failures across service boundaries.

Each request gets a trace ID. Each hop within a service creates a span with timing data. Spans form a tree showing the call hierarchy and where time was spent.

Tools: Jaeger (CNCF open-source, Uber-originated), Zipkin, AWS X-Ray, Datadog APM, Grafana Tempo. Integration in Spring Boot: Micrometer + OpenTelemetry.

Metrics: Numerical measurements over time (CPU usage, request latency p99, error rate, throughput). Collected by Prometheus, visualized in Grafana. Used for alerting (PagerDuty) when SLOs are breached.

Logs: Structured or unstructured text records of what happened. Collected and indexed by ELK Stack (Elasticsearch, Logstash, Kibana) or Loki + Grafana. Useful for root-cause analysis after an incident.

Traces: End-to-end request journeys across microservices. Jaeger, Zipkin. Useful to find which service is causing latency in a distributed call chain.

An operation is idempotent if calling it multiple times produces the same result as calling it once. In distributed systems, network retries and "at-least-once" delivery mean the same request may arrive multiple times.

Without idempotency: A payment might be charged twice if the client retries a timed-out request.

How to implement: Assign a unique idempotency key (UUID) to each request. The server stores processed keys in a database or Redis. On duplicate key: return the original response without reprocessing. Common in payment APIs (Stripe, Razorpay use idempotency keys).

Named after ship bulkheads that prevent water from flooding the whole ship, the Bulkhead pattern isolates failures by allocating separate resource pools (thread pools, connection pools) for different services or features.

Without bulkhead: One slow downstream service exhausts the shared thread pool — all other requests fail even for unrelated features.

With bulkhead: Each downstream service or feature gets its own isolated thread pool. A failure in one pool doesn't affect others. Implemented with Resilience4j's @Bulkhead annotation or via separate ExecutorService instances.

The 12-Factor App is a methodology for building cloud-native, microservices-ready applications. Key principles most asked in interviews:

III. Config: Store config in environment variables, not hardcoded or in the repo.
VI. Processes: Execute as stateless processes — no sticky sessions, session state in Redis/DB.
VIII. Concurrency: Scale out via process model (horizontal scaling, not vertical).
IX. Disposability: Fast startup, graceful shutdown (handle SIGTERM to finish in-flight requests before exiting).
XI. Logs: Treat logs as event streams — write to stdout, let infrastructure aggregate them.