Microservices Interview Questions

Microservices are an architectural style that structures an application as a collection of loosely coupled, independently deployable services, each responsible for a specific business capability.

Microservices provide scalability, flexibility, improved fault tolerance, ease of deployment, and better development speed by enabling parallel development of independent services.

Monolithic architecture is a single, unified application, while microservices consist of small, independent services that communicate over the network.

Spring Cloud is a set of tools and frameworks for building cloud-native microservices architectures, including services like service discovery, configuration management, and circuit breakers.

A service registry is a database where microservices register themselves and discover other services, allowing them to dynamically discover and communicate with each other.

An API Gateway is a server that acts as an entry point to a microservices system, routing requests, aggregating results, and managing security, load balancing, and API versions.

The circuit breaker pattern is used to prevent a microservice from making calls to a failing service, allowing the system to fail gracefully and recover.

Service discovery is the process by which microservices can automatically discover and interact with each other by dynamically registering and looking up services in a service registry.

Spring Boot simplifies the development of microservices by providing a rapid way to create stand-alone, production-grade Spring-based applications with minimal configuration.

A container is an isolated environment where a microservice runs, providing consistency across different environments, often using Docker.

A message broker like Kafka or RabbitMQ allows communication between microservices through messaging queues, ensuring decoupling and asynchronous communication.

A distributed database stores data across multiple physical locations to improve scalability, availability, and fault tolerance in a microservices architecture.

Event-driven architecture is an approach where microservices communicate via events, making systems more flexible, decoupled, and reactive to state changes.

Container orchestration systems like Kubernetes manage the deployment, scaling, and operation of containers, ensuring high availability and resource optimization.

Synchronous communication requires the client to wait for a response from the server (e.g., REST), while asynchronous communication allows the client to continue processing while awaiting a response (e.g., messaging queues).

Spring Cloud Config is a centralized configuration management service that allows storing and accessing configuration properties for microservices across different environments.

Docker is a platform that enables the creation, deployment, and management of containers, providing lightweight and consistent environments for microservices.

Monitoring is crucial in microservices to track performance, health, and behavior, using tools like Prometheus, Grafana, or ELK stack to gather and visualize metrics.

Challenges include managing distributed systems, data consistency, service discovery, API management, and handling inter-service communication and failures.

A Saga coordinates a business transaction as a sequence of local transactions. Each step publishes an event or invokes the next service, and a compensating action reverses its business effect when a later step fails; it does not provide a traditional distributed ACID transaction.

Give the operation a stable idempotency key, persist the key with the result or state transition, and return the original result for retries. Enforce uniqueness at the database boundary and design message consumers to tolerate duplicate delivery because network retries are normal.

Retry only transient failures, set a finite attempt limit and deadline, use exponential backoff with jitter, and avoid retrying non-idempotent operations unless they are protected by an idempotency design. Combine retries with timeouts, circuit breakers, and bulkheads so a failing dependency does not exhaust resources.

Eventual consistency means replicas or services may temporarily disagree but converge after successful propagation. Design read models and UI states that communicate pending work, use versioning or timestamps where needed, and choose a strongly consistent workflow for invariants that cannot tolerate temporary divergence.

Metrics summarize behavior, logs provide detailed events, and distributed traces connect spans across service boundaries using propagated context. A production system usually needs all three, with sampling and retention policies that control cost without hiding important failures.

The service writes its business change and an event record in the same local database transaction. A separate publisher then delivers the outbox event to the broker and marks it processed, preventing the dual-write gap; consumers still need idempotency because delivery can be repeated.

Contract tests verify that a provider and consumer agree on request, response, and event schemas without requiring every service to run together. They catch breaking API changes earlier than end-to-end tests, but they do not replace authorization, resilience, performance, or workflow tests.

Prefer backward-compatible additive changes, define deprecation and support windows, and use explicit versioning only when the contract must change incompatibly. Publish schemas and examples, monitor client usage, and remove old versions only after an announced migration path and evidence that consumers have moved.