Microservices questions often arrive in chains: a broad architecture prompt, then a sharp follow-up on data consistency, deployment, or a specific service you owned. Strong answers connect patterns to a real system you operated.
Topics interviewers expect you to know
- Service boundaries — domain-driven design vs premature splitting.
- Sync vs async communication — REST/gRPC vs message queues and event buses.
- Data ownership — database-per-service, eventual consistency, read models.
- Resilience — timeouts, retries, circuit breakers, bulkheads, idempotency keys.
- Observability — distributed tracing, correlation IDs, SLOs per service.
- Deployment — independent releases, feature flags, backward-compatible contracts.
Answer the latest question, not the first one
Interviewers sometimes stack topics in one breath: “Have you used polymorphism? Can you explain microservices?” The second clause is usually the active question. Pause, confirm what they want depth on, then answer that slice with a concrete example from your resume.
One story beats ten definitions
Pick a migration or greenfield service: why you split (or merged) services, how you handled cross-service transactions, what broke in production, and what metrics improved. A copilot helps recall service names, queue topics, and latency numbers from uploaded resume context.