Microservices Interview Questions and Answers

A microservice architecture structures an application as a set of small, independently deployable services, each built around a business capability, owning its own data store and communicating over the network.

A monolith packages all functionality into one deployable unit. It is simpler to develop, test and deploy early, and intra-process calls are fast and transactional.

Microservices bring independent scaling, team autonomy, fault isolation and the freedom to choose technology per service. The costs are real: network latency, partial failure, distributed data consistency, harder debugging, and significant operational and observability investment. You cannot refactor across service boundaries with the compiler as easily.

The right question is not which is better but whether the organization, domain understanding and operational maturity justify the overhead. Many successful systems start as a modular monolith and extract services only when a clear boundary and scaling pressure exist.

An API gateway is the single entry point for clients, sitting in front of backend services. It typically handles:

• Request routing to the correct service.
• Authentication and authorization, terminating TLS and validating tokens.
• Rate limiting, quotas and basic request validation.
• Response aggregation or transformation, sometimes exposing a Backend for Frontend tailored to a client.
• Observability: access logs, metrics, tracing headers, correlation ids.

routes:
  - path: /orders/**
    uri: lb://order-service
    filters: [TokenRelay, RateLimit]

Benefits are a smaller client surface and consistent cross-cutting concerns. Risks are a single point of failure, a potential bottleneck and a temptation to accumulate business logic. Keep it thin, make it highly available, and avoid coupling it to service internals. Service meshes move some of these concerns to sidecars, but the gateway usually remains the public edge.

In a dynamic environment, service instances start, stop and move, so callers cannot rely on fixed hostnames. Service discovery maintains a registry of healthy instances and lets clients resolve a logical service name to a live address.

Two patterns:

• Client-side discovery: the caller queries the registry (Consul, Eureka) and load-balances itself. Fewer hops but discovery logic in each client.
• Server-side discovery: the caller hits a load balancer or virtual IP, and the platform (Kubernetes Services, cloud load balancers) routes to a healthy instance. Simpler clients, one extra hop.

# Kubernetes resolves this name to ready pods
http://order-service.default.svc.cluster.local

Health checks are essential so unhealthy instances are removed quickly. In Kubernetes, DNS plus a Service is built-in discovery; for VMs you typically need a registry. Combine discovery with retries, timeouts and circuit breakers so a stale address does not cascade into an outage.