20 Microservices Questions Every Senior Java Developer Should Know

If you've worked with Spring Boot for a few years, you can probably build a REST API in your sleep.

But here's the reality:

Building a microservice isn't what makes you a senior engineer.

Understanding why distributed systems fail—and how to design them to survive—does.

After interviewing developers and working on enterprise microservices, I've noticed something interesting.

Many candidates know Spring annotations.

Far fewer understand architecture.

The questions below aren't just interview questions.

They're the concepts every Senior Java Developer should master before designing or operating production microservices.

1. What problem do microservices actually solve?

The goal isn't smaller services.

It's enabling independent deployment, team autonomy, scalability, and faster delivery.

If a monolith already achieves those goals, microservices may not provide enough benefit to justify the added operational complexity.

2. How do you determine microservice boundaries?

Not by database tables.

Not by UI pages.

Not by technical layers.

The best boundaries come from business domains and bounded contexts.

Poor boundaries lead to distributed monoliths.

3. Why are distributed transactions a bad idea?

Two-Phase Commit introduces latency, availability issues, and tight coupling.

Modern systems typically use the Saga pattern with compensating actions to achieve eventual consistency.

4. What is eventual consistency?

In distributed systems, data across services is not always synchronized immediately.

Temporary inconsistencies are expected.

Applications should be designed to tolerate them.

5. What is the Saga Pattern?

A Saga breaks a business transaction into a sequence of local transactions.

If one step fails, compensating actions undo the completed work.

This avoids global distributed transactions.

6. What is the Outbox Pattern?

Publishing events directly after a database commit can lead to inconsistencies if the event broker is unavailable.

The Outbox Pattern stores events in the same local transaction as business data, then publishes them asynchronously to ensure reliable delivery.

7. Why shouldn't microservices share a database?

A shared database creates hidden coupling.

Schema changes ripple across teams.

True service autonomy requires each service to own its data and communicate through APIs or events.

8. What is API Gateway?

An API Gateway provides a single entry point for clients.

It centralizes authentication, routing, rate limiting, request aggregation, and monitoring, reducing duplicated infrastructure logic across services.

9. What is Service Discovery?

In cloud environments, service instances are dynamic.

Service Discovery allows applications to locate each other through registries or platform-native mechanisms instead of hard-coded addresses.

10. How do Circuit Breakers improve resilience?

When downstream services fail, Circuit Breakers stop repeated requests, preventing cascading failures and allowing systems to recover gracefully.

11. What is the Bulkhead Pattern?

Bulkheads isolate resources such as thread pools or connection pools.

A failure in one workload cannot consume all system resources and impact unrelated functions.

12. How should microservices communicate?

There is no single answer.

Choose based on the use case:

• REST for synchronous APIs

• gRPC for high-performance internal communication

• Kafka or RabbitMQ for asynchronous messaging

• Events for loose coupling

The communication style should match the business requirement, not developer preference.

13. Why is idempotency important?

Network retries happen.

Messages may be delivered more than once.

Endpoints and consumers should safely handle duplicate requests without creating inconsistent state.

14. What is CQRS?

Command Query Responsibility Segregation separates write operations from read operations.

This allows each side to scale independently and optimize for different workloads.

15. What is distributed tracing?

A single user request may traverse dozens of services.

Distributed tracing correlates these interactions, making it possible to diagnose latency and failures across the entire request path.

Tools such as OpenTelemetry and Jaeger are commonly used.

16. How do you secure microservices?

Security extends beyond authentication.

A comprehensive approach includes:

• OAuth2 / OpenID Connect

• JWT validation

• Mutual TLS

• Least-privilege authorization

• Secret management

• Zero Trust networking

17. Why do microservices become distributed monoliths?

Common causes include:

• Shared databases

• Excessive synchronous communication

• Poor service boundaries

• Tight deployment dependencies

• Shared domain logic

Independent deployment should be the goal.

18. What metrics matter in production?

CPU and memory are only the beginning.

High-performing teams also monitor:

• Latency

• Throughput

• Error rates

• Availability

• Queue depth

• Retry rates

• Business KPIs

Observability is as important as functionality.

19. When should you NOT use microservices?

Microservices introduce operational complexity.

For small teams, early-stage products, or simple domains, a well-structured modular monolith often provides better outcomes with lower cost.

Architecture should fit the organization—not the trend.

20. What separates a Senior Java Developer from a Staff Engineer?

A Senior Developer builds reliable services.

A Staff Engineer designs reliable systems.

They think about:

• Architecture

• Scalability

• Reliability

• Operational excellence

• Business trade-offs

• Team productivity

• Long-term maintainability

Technology is only part of the job.

Understanding systems is what truly defines seniority.

Final Thoughts

Microservices are no longer new.

Frameworks like Spring Boot, Kubernetes, and Kafka have become mainstream.

What distinguishes experienced engineers today isn't whether they can write another REST endpoint.

It's whether they understand the architectural principles behind resilient distributed systems.

The best interviews no longer focus on syntax.

They explore how candidates reason about trade-offs, failure modes, scalability, consistency, and operational complexity.

Because in production, architecture—not code—is what determines whether a system succeeds.

If you were interviewing a Senior Java Developer today, what microservices question would you definitely ask? Share it in the comments.