Crack Microservices Interviews with These Real Scenarios

I would use the Strangler Fig pattern. Instead of a big bang rewrite, I'd identify a domain with the least dependencies — like Notifications or Search — and extract it first.

Step-by-step approach:

• Put an API Gateway in front of the monolith to intercept all traffic.
• Extract the lowest-dependency domain (e.g., Notifications) as the first standalone service.
• Route that domain's traffic through the gateway to the new service.
• Iteratively carve out other domains (User, Order, Payment) one by one.
• Decommission the monolith only after all domains are migrated and stable.

The key principle: the monolith and microservices coexist during the migration. You never do a full rewrite in one go.

Four signals to look for:

• Domain-Driven Design (DDD): Identify bounded contexts where responsibilities are clearly defined and isolated.
• Load Analysis: Focus on modules with high traffic or frequent deployments that slow down the whole monolith.
• Dependency Mapping: Look for components with minimal inbound/outbound dependencies — easiest to extract safely.
• Business Priority: Choose domains causing the most bottlenecks or delivering the most value independently.

Start with the domain that scores well across all four — typically a notification, reporting, or search service.

I would offload authentication to the API Gateway or a dedicated Identity Provider like Keycloak or Auth0.

How it works:

• The gateway validates the user's credentials and generates a signed JWT (JSON Web Token).
• This JWT is passed downstream in HTTP headers to every microservice.
• JWTs contain user roles and are cryptographically signed, so each microservice independently verifies the token — stateless, no database calls required.
• For authorization, each service checks the roles/claims embedded in the token against its own permission rules.

This approach eliminates the need for inter-service auth calls and scales well because JWT verification is CPU-only, not I/O-bound.

Never expose microservices directly to the client. All external traffic goes through an API Gateway.

What the gateway handles:

• Routing incoming requests to the correct downstream service.
• Authentication: validates credentials and issues JWTs.
• Rate limiting to prevent abuse and DDoS.
• SSL termination — services inside the cluster use plain HTTP.
• Response aggregation — the gateway can fan out to multiple services and combine results.

For mobile specifically, the Backend-For-Frontend (BFF) pattern sits between the gateway and the app. The BFF strips heavy fields the phone doesn't need and returns a lightweight, mobile-optimized payload from a single call.

Immediate response:

• Horizontal Pod Autoscaling (HPA) in Kubernetes: automatically spins up more pods based on CPU, memory, or custom metrics (like request queue length).
• CDN caching: offloads read traffic for static content and product images to edge servers near users.
• Live video specifically: break streams into short-lived segments (HLS or DASH), cache at edge servers — reduces origin server load by orders of magnitude.
• Circuit Breakers: prevent one slow service from cascading failures to the rest.
• Message queues: buffer bursts so downstream services process at a controlled rate rather than being overwhelmed.

The key design principle is independent scalability — only the overloaded service (e.g., Search or Payment) scales up, not the entire platform.

This is one of microservices' core advantages over monoliths — independent scalability.

• Each service has its own Kubernetes Deployment with its own HPA configuration.
• Search Service: add Redis caching and Elasticsearch to handle heavy read load. HPA scales pods on request count.
• Payment Service: buffer requests via Kafka/RabbitMQ so overload doesn't cause failures.
• Services must be stateless so new pods can start handling traffic immediately without warm-up.
• Use rate limiting at the API Gateway to protect low-capacity services like Login from spillover traffic.

Design principle: every service should be independently deployable, independently scalable, and stateless.

Sequential calls multiply latency. 4 calls at 200ms each = 800ms total. The fix is parallel execution.

Layered optimization strategy:

• Parallel async calls: fire all downstream requests simultaneously. Total time = slowest single service (~200ms instead of 800ms).
• Backend-For-Frontend (BFF): mobile app makes one call to the BFF, which gathers data from all services inside the high-speed internal network, strips unnecessary fields (4K images, full review text), and returns a lightweight payload.
• CQRS Materialized View: pre-aggregate all product data into a single read-optimized document in MongoDB or Elasticsearch. One query, no fan-out.

For read-heavy scenarios, the CQRS materialized view is the best long-term approach — it removes all runtime fan-out.

• Distributed cache (Redis or Memcached): serves 95% of requests without hitting the database.
• CDN: caches all product images and static assets at edge locations near users.
• Read Replicas: route all SELECT queries to read replicas; the primary database only handles writes.
• Cache invalidation strategy: on product update, invalidate only the affected cache key rather than flushing the entire cache.

With this setup, the primary database handles only write traffic, and the cache absorbs almost all reads — enabling near-linear horizontal scaling.

Traditional ACID transactions don't work across independent services. The solution is the Saga Pattern.

Two implementations:

• Choreography: each service publishes an event after its local transaction. If Payment fails, it publishes a PaymentFailed event. The Inventory service listens and runs a compensating transaction (restock the item). No central coordinator.
• Orchestration: a central Order Orchestrator service manages the entire workflow, calling each service in sequence and triggering rollback commands if any step fails.

Choosing between them:

• Choreography: simpler for short flows, but harder to trace and debug as complexity grows.
• Orchestration: easier to monitor and reason about, but introduces a single point of failure in the coordinator.

Microservices should never do distributed joins at query time. The solution is Change Data Capture (CDC).

Design:

• Use CDC tools like Debezium or Kafka Connect to listen to the transaction logs (binlogs) of each service's database.
• Stream those changes into a central Data Warehouse or Data Lake (Snowflake, BigQuery, Amazon Redshift) in near-real-time.
• Business intelligence tools like Tableau or Metabase run heavy analytical queries against the warehouse — not the operational databases.

This decouples reporting from operational services. The warehouse is the source of truth for analytics; the individual DBs are the source of truth for their own domains.

The Search Service shouldn't query Product, Pricing, and Reviews via API on every search. That creates tight coupling and high latency.

Solution: CQRS + Event Sourcing

• Product, Pricing, Inventory, and Review services publish events to Kafka whenever their data changes.
• The Search Service consumes these events and builds its own flattened, read-optimized index in Elasticsearch.
• Search queries hit only Elasticsearch — no fan-out to other services at query time.
• Data is eventually consistent, which is acceptable for search.

This pattern — each service owning a materialized read model built from events — is the cornerstone of scalable, decoupled microservices.

Make order creation asynchronous. Don't block the user on Payment being available.

Implementation:

• Accept the order and persist it in a 'Pending' state in the Order database.
• Drop a ProcessPayment event onto a message broker (Kafka or RabbitMQ).
• Show the user: 'Order received, awaiting payment confirmation.'
• When Payment recovers, it processes the queued messages and updates the order status to Confirmed or Failed.
• If Payment fails on processing, a compensating transaction cancels the order and notifies the user.

The system achieves eventual consistency. The user experience degrades gracefully — orders aren't lost, they're just delayed.

This is a cascading failure. The Order service's threads are stuck waiting for Payment to respond, causing thread pool exhaustion. The pool fills up, Order starts rejecting all requests, and the failure propagates upstream.

Fix: Circuit Breaker Pattern (Resilience4j)

• Closed state: traffic flows normally.
• Open state: if Payment failures/timeouts exceed a threshold (e.g., 50% failure rate over 10s), the circuit opens. Order service instantly returns a fallback — no threads blocked.
• Half-Open state: after a cooldown, a few test requests go through. If Payment responds, circuit closes. If they fail, it snaps back to Open.

The circuit breaker must be combined with a fallback — return cached data, a default response, or a user-friendly error. Never just fail silently.

Intermittent failures are typically transient network blips. The fix is Retry with Exponential Backoff and Jitter.

Why plain retries are dangerous:

During a flash sale, 10,000 concurrent requests retrying instantly after a 503 causes a thundering herd — amplifying the failure instead of recovering from it.

Correct approach:

• Exponential backoff: retry at 1s, 2s, 4s intervals.
• Jitter: add ±200ms randomness (e.g., 1.1s, 1.8s) to spread retry load across time.
• Pair with Circuit Breaker: if failure rate hits 50% in a 10-second window, stop retrying and open the circuit.
• Observability alert: trigger PagerDuty or Slack if 5xx error rate exceeds 5% in a one-minute window — catch it before it becomes an outage.

Prevent this from affecting all users by using Blue-Green or Canary deployment strategy — never deploy directly to 100% of traffic.

Blue-Green rollback:

• Two identical environments: Blue (current stable) and Green (new version).
• Route traffic to Green and monitor error rates.
• If errors spike, switch the load balancer back to Blue — instant rollback, zero downtime.
• For database: always make schema changes backward-compatible (additive only). Rolling back code should never break the database state.

Canary strategy:

• Route 5% of traffic to the new version first.
• Monitor error rates, latency, and business metrics for that cohort.
• Gradually increase to 10%, 25%, 100% only if metrics are healthy.

Deployment strategy options in Kubernetes:

• Rolling Update: replaces old pods one by one. Some old, some new pods serve traffic simultaneously. Zero downtime if the new version is backward-compatible.
• Blue-Green: spin up an entirely new deployment, switch load balancer, instant cutover or instant rollback.
• Canary: gradually shift traffic percentage to the new version.

Database migrations — the Expand and Contract pattern:

• Phase 1 (Expand): deploy a backward-compatible schema change — add the new column while keeping the old one. Both old and new code work.
• Phase 2: do the rolling update. Old and new pods coexist reading both columns.
• Phase 3 (Contract): once all pods are updated, remove the old column in a subsequent release.

Kubernetes readiness probes ensure traffic only goes to pods that have fully started and passed health checks.

This is a contract breaking problem. The solution is Consumer-Driven Contract Testing.

• The Order Service (consumer) defines exactly what it expects from the Payment API as a contract (using tools like Pact).
• The Payment team's CI/CD pipeline runs these consumer contracts as tests on every build.
• If a Payment change breaks the Order contract, the build fails before deployment — the breaking change never reaches production.
• API versioning: use URI versioning (/v1/, /v2/) and keep v1 active until all consumers have migrated.

The rule: a service can add new fields to its API contract, but it must never remove or rename existing fields without a versioned migration path.

Configuration should be centralized and externalized — never hardcoded inside service binaries.

Tools by use case:

• Kubernetes ConfigMaps: non-sensitive configs (feature flags, URLs, timeouts) per service per environment.
• Kubernetes Secrets or HashiCorp Vault: API keys, DB passwords, certificates — encrypted at rest, access-controlled per service.
• AWS SSM Parameter Store / AWS Secrets Manager: managed secrets in AWS environments with IAM-based access policies.
• Spring Cloud Config (JVM ecosystems): centralized config server with environment-specific profiles.

Services load config dynamically at startup or runtime. No code changes needed to deploy the same binary across dev, staging, and prod — only the config differs.

Implement Distributed Tracing using OpenTelemetry with Jaeger or Zipkin as the backend.

How it works:

• The API Gateway generates a unique Trace-ID (correlation ID) for every incoming request.
• This Trace-ID is passed in HTTP headers to all downstream services.
• Each service creates a Span within that trace, recording start time, end time, and any errors.
• All logs are aggregated in a central system (ELK Stack or Splunk) with the Trace-ID attached.
• In Jaeger's UI, you can visualize the entire call tree and see exactly which service introduced the latency or threw the error.

Without distributed tracing, debugging a failure across 5 services means manually correlating timestamps in 5 separate log streams — practically impossible at scale.

Infrastructure metrics (CPU, RAM) tell you if the system is sick. Business metrics tell you if the business is sick. They need separate pipelines.

Design:

• Each microservice emits structured business events (OrderPlaced, PaymentFailed, CartAbandoned) to a message broker or directly to Prometheus custom metrics.
• Prometheus scrapes and stores these time-series metrics.
• Grafana dashboards visualize conversion rates, payment success rates, and failure trends in real-time.
• Prometheus Alertmanager fires alerts when conditions are met — e.g., 10 PaymentFailed events in the last 1 minute triggers a Slack, PagerDuty, or Teams notification.

Business and infrastructure metrics share the same tooling (Prometheus + Grafana) but are tracked on separate dashboards with separate alert thresholds.

This is the service discovery problem. Hardcoded IPs break as soon as pods scale or restart.

Solutions:

• Kubernetes (native): Kube-DNS and ClusterIP services. Pods just call http://payment-service and K8s routes it to a healthy pod. Fully automatic.
• Outside Kubernetes: use a Service Registry like Eureka (Spring) or Consul. When a pod starts, it registers its IP. When Order wants to call Payment, it queries the registry for a live Payment IP and load-balances across results.
• Service Mesh (Istio/Linkerd): handles discovery, load balancing, retries, and mTLS transparently — service code makes a plain HTTP call, the mesh sidecar handles routing.

• REST: external client-facing APIs (Web/Mobile to API Gateway). Standard, human-readable, widely supported. Use when the consumer is outside your infrastructure.
• gRPC: internal synchronous service-to-service calls requiring high performance and low latency. Binary protocol (Protobuf), multiplexed over HTTP/2, 5-10x faster than REST for internal calls. Use for Order → Inventory real-time stock checks.
• Kafka: asynchronous, event-driven communication where the producer doesn't need an immediate response. Fire-and-forget — like triggering a Notification after an order is placed. Use when decoupling is more important than immediacy.

Decision rule:

External → REST. Internal real-time → gRPC. Internal async / event-driven → Kafka.

Microservices are fundamentally language-agnostic. They communicate over standard network protocols, not in-process function calls.

• REST + JSON: use OpenAPI/Swagger to define the API contract. Any language can consume a JSON REST API.
• gRPC + Protobuf: the .proto schema file is the language-neutral contract. Generate client stubs for both Java and .NET from the same schema.
• Message broker (Kafka): both services publish and consume from shared topics as plain JSON or Avro/Protobuf messages — language is irrelevant.

The contract (OpenAPI spec, .proto file, or Avro schema) is the source of truth. As long as both services adhere to it, the underlying tech stack doesn't matter.

Options based on consistency requirement:

• Real-time accuracy required: switch from REST to gRPC. Binary Protobuf over HTTP/2 is significantly faster than JSON over HTTP/1.1 for internal calls.
• Eventual consistency acceptable: cache inventory state in the Order service using Redis. Refresh from Inventory service on a TTL or via Kafka events.
• Decoupled reads: implement CQRS — the Order service maintains its own read-optimized view of inventory, updated via Kafka events from the Inventory service. Zero synchronous calls at query time.

In most e-commerce scenarios, showing slightly stale stock counts (eventual consistency) is acceptable, making the CQRS+Kafka approach the best long-term solution for latency.