Amazon Interview Microservices Interview Questions

Microservices architecture structures an application as a collection of small, independently deployable services. Each service handles a specific business capability and can be developed, deployed, and scaled individually.

Monolithic apps are tightly coupled and deployed as a single unit. Microservices break the system into small independent services with separate deployments. Microservices offer better scalability and fault isolation.

Key advantages include independent deployment, fault isolation, easier scaling, technology flexibility, and faster development cycles through small focused teams.

Microservices introduce distributed system complexity, data consistency issues, operational overhead, and challenges in monitoring, logging, and networking.

Service discovery enables dynamic locating of service instances. It may be client-side or server-side using tools like Eureka, Consul, or Zookeeper for registry and lookup.

An API Gateway is the single entry point for client requests. It handles routing, authentication, rate limiting, caching, and protocol translation. Examples include Kong, Zuul, and NGINX.

Synchronous communication uses REST or gRPC. Asynchronous communication uses queues like Kafka or RabbitMQ. The choice depends on latency and resilience needs.

Each service owns its own database to maintain autonomy. Distributed transactions are managed via sagas or event-driven approaches to ensure consistency.

Synchronous services wait for responses (REST). Asynchronous services communicate without waiting using message brokers. Async improves resilience but adds complexity.

Eventual consistency allows data to be temporarily inconsistent across services but ensures it becomes consistent over time. Techniques include CQRS, event sourcing, and sagas.

The circuit breaker prevents cascading failures by stopping calls to a failing service. It opens when failures exceed a threshold and resets after the service recovers. Tools include Hystrix and Resilience4j.

Load balancing distributes traffic across multiple service instances. It improves performance and fault tolerance using tools like NGINX, HAProxy, or Envoy.

Security includes authentication (OAuth2, JWT), authorization, TLS communication, API Gateway enforcement, and service-to-service authentication.

Centralized logging (ELK), monitoring (Prometheus, Grafana), and distributed tracing (Jaeger, Zipkin) help troubleshoot and monitor microservices health.

Microservices are packaged into Docker containers for portability and consistency. Orchestration tools like Kubernetes manage scaling, networking, and deployments.

Kubernetes automates deployment, scaling, self-healing, load balancing, and service discovery for containerized microservices using declarative YAML configurations.

By deploying multiple instances, using load balancing, automatic failover, and stateless services with resilient storage. Ensures minimal downtime.

Sagas coordinate distributed transactions by using a sequence of local transactions. If one step fails, compensating actions revert previous changes.

Services communicate through events using message brokers like Kafka or RabbitMQ. Event-driven architecture improves decoupling, scalability, and resilience.

Microservices scale horizontally by adding instances. Orchestrators like Kubernetes distribute traffic across instances using load balancing.

CQRS separates read operations (queries) and write operations (commands) into different models. It improves scalability, performance, and security. CQRS is often combined with event sourcing for robust distributed architectures.

Event Sourcing stores all changes to an application's state as a sequence of events instead of only storing the latest state. The current state is rebuilt by replaying events, enabling audit trails, temporal queries, and strong consistency.

The Saga pattern breaks a distributed transaction into smaller local transactions with compensating actions for rollback. It ensures eventual consistency and is implemented via choreography (events) or orchestration (coordinator service).

Observability is the ability to understand a system’s internal state from external signals. It includes logging, metrics, and distributed tracing to diagnose issues in distributed systems.

Distributed tracing tracks a single request across multiple microservices using trace IDs and span IDs. It helps identify latency, failures, and bottlenecks. Tools include Jaeger and Zipkin.

A circuit breaker prevents repeated calls to a failing service, avoiding cascading failures. A fallback mechanism provides a default response when a service is unavailable. Tools include Hystrix and Resilience4j.

The bulkhead pattern isolates service resources, such as thread pools or memory, to prevent one failing process from impacting others. It improves resilience and fault isolation.

Rate limiting controls how many requests can be handled over a time period. It protects services from overload and DoS attacks and is usually implemented at the API Gateway using tokens or sliding windows.

Retries reattempt failed operations, while exponential backoff increases the wait time between retries to minimize load. Combined with circuit breakers, they prevent service saturation.

The sidecar pattern deploys helper components alongside the main service in the same pod or host. Used for logging, configuration, monitoring, and proxies, especially in Kubernetes environments.

API versioning avoids breaking existing clients by exposing updated versions. Methods include URL versioning (v1), query parameters, or custom headers. It ensures backward compatibility.

A service mesh is an infrastructure layer that handles service-to-service communication. It manages routing, security, and observability. Examples include Istio, Linkerd, and Consul Connect.

Configuration is externalized using config servers or environment variables. Tools like Spring Cloud Config, Consul, and Vault ensure consistent, secure handling across environments.

Blue-green deployment runs two identical environments. The new version (green) is deployed alongside the old (blue), and traffic switches once validated, minimizing downtime.

Canary deployment releases the new application version to a small group of users first. If stable, the rollout continues. It reduces deployment risk significantly.

Use centralized logging (ELK, Graylog), include correlation IDs, avoid sensitive data in logs, and use structured log formats like JSON for easier ingestion.

Resilience is achieved using retries, timeouts, circuit breakers, bulkheads, autoscaling, and health checks. Stateless services simplify recovery and scaling.

Liveness probes check if the service is running. Readiness probes verify if it is ready to accept traffic. Orchestrators like Kubernetes use these checks to manage service availability.

Idempotency ensures that repeating the same request produces the same result. It is critical for retries, payment processing, and message handling to prevent duplication.

Monitoring includes collecting metrics like latency, error rate, and throughput. Tools such as Prometheus, Grafana, and New Relic provide dashboards and alerts. Distributed tracing detects bottlenecks across services.

Event-driven architecture means services communicate via published events instead of synchronous calls.

This improves loose coupling, scalability, and resilience. Events can be domain events, integration events, or system events.

Request-driven: Services call each other synchronously using HTTP/gRPC.

Event-driven: Services publish/subscribe to events asynchronously.

Event-driven provides higher decoupling and responsiveness.

Message brokers handle asynchronous communication.

Examples: Kafka, RabbitMQ, AWS SQS/SNS.

They ensure durability, ordering, and delivery guarantees.

Pub/Sub: Publisher sends events to multiple subscribers.

Message Queue: Messages are consumed by one or more consumers.

Both enable async processing and load leveling.

Kafka is a distributed event streaming platform.

Supports partitioning, replication, high throughput, and fault tolerance.

Use acknowledgments, retries, DLQs, idempotent consumers, and transactional outbox pattern.

Events are written to an outbox table inside the same DB transaction.

A background process publishes them to the message broker to guarantee consistency.

Through horizontal scaling, partitioning/sharding, and stateless services.

CQRS: Separates read/write models.

Event sourcing: Stores state as events.

Together, they boost performance, auditability, and resilience.

Eliminates blocking, increases throughput, smooths spikes, and makes the system resilient.

Data converges over time instead of instantly.

Enabled by sagas, compensating actions, and idempotent operations.

Backpressure occurs when consumers can't keep up with event producers.

Solved via throttling, buffering, or rate limiting.

DLQs store messages that fail processing.

Used for debugging and preventing message loss.

Using CDC, event streams, materialized views, and distributed caching.

Orchestration: Central controller directs saga.

Choreography: Services react to each other's events.

Monitor throughput, consumer lag, processing errors using logs, metrics, tracing, and dashboards.

Non-blocking async programming using data streams.

Frameworks: Reactor, RxJava, Spring WebFlux.

Horizontal: Add more instances (preferred).

Vertical: Add more CPU/RAM to a single instance (limited).

Kafka ensures ordering per partition; RabbitMQ ensures FIFO per queue.

Idempotent consumers ensure consistent processing.

Use async communication, caching, stateless services, monitoring, circuit breakers, retries, and backpressure handling.