What microservices are, microservices vs monolith, benefits and challenges, API gateway responsibilities (routing, traffic, security, load balancing), synchronous vs asynchronous communication, message brokers and inter-service risks.
Published September 25, 2026
Microservices questions reward balanced answers. Interviewers are wary of candidates who treat microservices as automatically better. For every benefit you name, mention its cost: operational complexity, network failures, data consistency. Concrete Spring examples (Spring Cloud Gateway, Kafka, Resilience4j) make your answers credible.
Short answer: An architectural style in which an application is built as a set of small, independently deployable services. Each one is organised around a business capability (orders, payments, inventory), owns its data, and communicates with the others over the network (HTTP/REST, gRPC or messaging). Each service can be developed, deployed and scaled by its own team.
Key points to cover:
Learn it in depth → Monolith to Microservices Decomposition
Short answer: A monolith is built, deployed and scaled as one unit, usually with a single shared database. Microservices split the system into many independently deployed services, each with its own database.
| Monolith | Microservices | |
|---|---|---|
| Deployment | One artifact; any change redeploys everything | Each service deploys independently |
| Scaling | Scale the whole application | Scale only the hot services |
| Data | One shared database, local ACID transactions | A database per service; distributed consistency |
| Calls | In-process method calls (fast, reliable) | Network calls (latency, partial failure) |
| Team fit | Small teams, early products | Many teams, clear domain boundaries |
| Operations | Simple | Needs CI/CD, observability, service discovery |
Key points to cover:
Short answer:
Short answer:
Key points to cover:
Learn it in depth → Why Microservices Fail
Short answer: It's the single entry point for external clients. It routes each request to the right service, and centralises cross-cutting concerns: authentication and token validation, rate limiting, TLS termination, CORS, request and response transformation, caching, and logging and metrics. Clients see one API, instead of dozens of internal services.
# Spring Cloud Gateway
spring:
cloud:
gateway:
routes:
- id: orders
uri: lb://order-service # load-balanced through service discovery
predicates: [ Path=/api/orders/** ]
filters: [ StripPrefix=1 ]
Key points to cover:
Learn it in depth → API Gateway
Short answer:
Short answer:
Common trap: relying only on the gateway. Services should still verify identity and perform fine-grained authorisation themselves ("zero trust"), because internal traffic can bypass the gateway.
Learn it in depth → Spring JWT Authentication
Short answer: It looks up the healthy instances of a service (from a service registry such as Eureka, or from Kubernetes Services and DNS), and spreads requests across them using an algorithm:
Instances that fail their health checks are removed automatically.
Key points to cover:
lb://service-name URI uses Spring Cloud LoadBalancer. On Kubernetes, the platform's Service usually does this for you.Learn it in depth → Load Balancing
Short answer: In two styles:
RestClient, WebClient or OpenFeign), or gRPC, for queries that need an immediate answer.Learn it in depth → Inter-Service Communication Choices
Short answer: Synchronous: the caller sends a request and waits for the response, so both services must be up at the same time (HTTP or gRPC). Asynchronous: the sender publishes a message and carries on. The receiver processes it whenever it can, and the two are decoupled in time and availability (a message broker).
| Synchronous | Asynchronous | |
|---|---|---|
| Coupling | Temporal: both must be available | Decoupled through the broker |
| Latency seen by the user | Adds up along the call chain | Immediate response; work completes later |
| Failure handling | Timeouts, retries, circuit breakers | Retries, dead-letter queues, idempotent consumers |
| Consistency | Easier to reason about | Eventual |
| Examples | Price lookup, authentication check | Order events, notifications, analytics |
Short answer: A broker receives, stores and delivers messages between producers and consumers. It decouples services, buffers load spikes, enables publish/subscribe fan-out (one event, many consumers), and supports retries and dead-letter queues, with delivery guarantees (at-least-once is typical).
Key points to cover:
Learn it in depth → Messaging Technology Choices
Short answer:
Key points to cover:
Learn it in depth → Timeout Strategy
Q: How small should a microservice be? A: Size it by business capability (a bounded context), not by lines of code. It should be small enough for one team to own and change independently, and big enough that most requests don't need chatty calls to other services.
Q: REST or gRPC between services? A: REST/JSON is universal, easy to debug, and browser-friendly. gRPC (HTTP/2 + Protobuf) is faster, strongly typed, and supports streaming, so it's good for high-volume internal calls. Many systems use REST at the edge and gRPC internally.
Q: What is the "distributed monolith" anti-pattern? A: Services that must be deployed together, share a database, or call each other synchronously in long chains. You get all the costs of microservices, and none of the independence.
Q: How do you keep a synchronous call chain from getting slow? A: Reduce the depth (aggregate at the gateway or a BFF), call services in parallel where possible, cache stable data, set tight timeouts, and move non-critical work to asynchronous events.