Microservices Interview Questions & Scenarios

A small, independently deployable service that owns one business capability and its data, communicating with other services over APIs or events.

A well-structured (modular) monolith for small teams and new products with unclear boundaries; microservices when multiple teams need to deploy independently, parts of the system have very different scaling needs, and the organisation has strong automation and observability.

By business capability and DDD bounded contexts — group what changes together, keep each service ownable by one team, and give each its own data.

Synchronously (REST, gRPC) when an immediate answer is needed, asynchronously (Kafka, RabbitMQ) for events and workflows — with timeouts, retries and circuit breakers on synchronous calls.

A registry (Eureka) or platform feature (Kubernetes Services) that maps service names to the current healthy instances, combined with load balancing.

Provides a single entry point that handles routing, authentication, rate limiting, load balancing, resilience and observability for client traffic.

With sagas — local transactions plus compensations — coordinated by events (choreography) or an orchestrator, events published through a transactional outbox, and idempotent consumers.

Timeouts, bounded retries with back-off and jitter, circuit breakers, bulkheads, rate limiting and fallbacks (Resilience4j), plus asynchronous communication where possible.

OAuth2/OIDC with an authorization server, JWT access tokens validated at the gateway and by every service (zero trust), object-level authorization, client-credentials tokens or mTLS for service-to-service calls, and TLS everywhere.

Distributed tracing with Micrometer Tracing / OpenTelemetry: a trace ID propagated in headers through HTTP and Kafka, spans exported to Zipkin/Jaeger/Tempo, and the same trace ID in every log line.

Externalized configuration — Spring Cloud Config backed by Git, or Kubernetes ConfigMaps — with secrets in Vault or a cloud secret manager, and refresh via @RefreshScope or a rollout.

Rolling, blue-green or canary deployments with readiness probes and graceful shutdown, backward-compatible APIs and events, and expand–contract database migrations.

A pyramid: many unit tests, integration tests with Testcontainers, consumer-driven contract tests between services, and a small number of end-to-end tests.

Each service owns its own database, giving loose coupling and independent schemas — but losing cross-service joins and ACID transactions, which are replaced by API composition, CQRS views and sagas.

Services that can't be deployed independently because of shared databases, tight synchronous coupling or shared libraries and release schedules.

Without protection, order-service threads pile up waiting and checkout fails, possibly taking other features down. With resilience: a timeout fails fast, the circuit breaker opens after repeated failures, and a fallback accepts the order as payment pending; an event or retry job charges the customer once payment recovers, and the user is told the order is being confirmed.

Open the trace for a slow request (Zipkin/Jaeger) to see which span is slow; check that service's metrics (latency percentiles, connection-pool and thread-pool saturation, GC) and its logs filtered by the trace ID; then fix the cause — a slow query, missing index, sequential calls that could be parallel, or a dependency without a timeout.

Yes — they're coupled at the schema level: a change by one team can break the other, and they can't scale or deploy independently. Assign the data to one owner; the other gets it through an API or by keeping its own copy updated from events.

Map business capabilities and bounded contexts; pick an edge capability with clear boundaries and real benefit (independent scaling or frequent change); put a gateway in front (strangler fig); extract it with its own data, using events to sync during the transition; repeat. Invest in CI/CD, observability and contract tests first.

A dual write: the order service saved the order and then failed to publish the event (or vice versa). Use a transactional outbox so the event is recorded in the same database transaction, make consumers idempotent, and add a reconciliation job to detect anything stuck.

Likely causes: pods receiving traffic before they're ready (missing or wrong readiness probe), pods killed before finishing in-flight requests (no graceful shutdown or too short a grace period), or a backward-incompatible change while old and new versions run together. Fix probes, enable graceful shutdown, and keep APIs, events and schemas backward compatible.

Broken object-level authorization: the service checks that a token is valid but not that the order belongs to the caller. Enforce ownership checks in the service (compare the token's subject or tenant with the resource), not just at the gateway.

Long synchronous chains multiply latency and failure probability. Cache or replicate the data A needs, call independent services in parallel, move non-blocking work to events, and revisit boundaries if services are always called together.