50 Microservices Interview Questions for Senior Java Developers

Model the workflow as a saga with durable states, explicit success transitions, and compensating actions. On shipment failure, decide whether to retry fulfillment, release inventory, and refund payment according to business rules. Compensations can fail or be non-instantaneous, so persist progress, make actions idempotent, and provide reconciliation for unresolved transactions.

Assume the event may be published more than once because the publisher cannot atomically commit a database status change with an external broker acknowledgement. Use stable event IDs, retryable publishing, and idempotent consumers with durable deduplication. The outbox protects against losing committed events, but end-to-end exactly-once business effects require additional application and storage guarantees.

Make stock reservation an atomic operation against an authoritative inventory state, using conditional database updates or appropriately coordinated reservation records. A normal cache read followed by a separate write cannot safely enforce stock invariants under concurrency. Redis can accelerate reads or participate in carefully designed atomic reservation logic, but persistence, failure recovery, and reconciliation remain necessary.

Apply retries only to failures that are likely transient and to operations that are safe to repeat. Use bounded attempts, exponential backoff with jitter, deadline awareness, and retry budgets; avoid multiplying retries across every dependency layer. Combine these with circuit breakers, bulkheads, and overload signals so recovery traffic does not overwhelm unhealthy services.

Cache previously validated public keys and plan overlapping key validity periods so existing tokens remain verifiable during rotation. Publish new verification keys before issuing tokens signed with them, and retain old keys until relevant tokens expire. Unknown signing keys must not be trusted merely because the JWKS endpoint is unavailable; define secure failure behavior and operational recovery procedures.

Kafka transactional processing does not automatically make an external MySQL update or payment-provider call part of the same atomic transaction. A crash between the external side effect and Kafka transaction completion can cause the operation to be attempted again. Use business-level idempotency keys, durable processing records, and reconciliation to prevent duplicate financial effects.

The asynchronous operation may run on another thread and database transaction before the original transaction commits. Spring transaction context does not automatically propagate across arbitrary asynchronous thread boundaries. Publish work through a transactional outbox for reliable delivery, or use an after-commit listener when its weaker delivery guarantees are acceptable.

Classify each dependency as essential or optional and define which partial results remain valid for users. Apply independent timeouts, bounded concurrency, and selective fallbacks such as cached ratings or omitted recommendations. Expose partial-data freshness or availability clearly, and avoid returning misleading success for missing critical information such as authoritative pricing.

Kafka preserves record order within an individual partition, not a total order across all partitions. Use a stable customer identifier as the partition key when per-customer ordering is required, and handle producer concurrency and retries appropriately. Include entity versions or sequence numbers so consumers can reject stale updates and detect gaps where business correctness requires it.

Inspect active, idle, and pending connection counts along with transaction duration and connection acquisition time. Look for leaked connections, long transactions, blocked SQL statements, slow network operations inside transactions, and excessive concurrent requests. Fix connection retention and query behavior before increasing pool size, because larger pools may worsen contention or exceed database connection capacity.

Identify business capabilities, data ownership, dependency relationships, and areas with independent change or scaling requirements. Use an incremental strangler approach, extracting bounded capabilities behind stable interfaces while keeping old and new paths operational during transition. Avoid splitting tightly coupled database operations prematurely; measure migration risk, operational overhead, and whether each extraction improves autonomy.

Inspect event-loop blocking, connection-pool saturation, pending connection queues, downstream latency, and reactive pipeline concurrency. Blocking JDBC calls or CPU-intensive work executed on event-loop threads can reduce responsiveness despite using a reactive HTTP client. Use appropriate schedulers for unavoidable blocking work, enforce concurrency limits, and compare end-to-end measurements rather than assuming reactive code is automatically faster.

Do not assume an asynchronously maintained search index reflects a committed database write immediately. Return the committed order directly from the authoritative service or provide a version-aware read path until the index catches up. Use Elasticsearch for search and discovery while defining explicit freshness guarantees for operations requiring immediate consistency.

Measure throughput, queueing, database connections, lock contention, and downstream saturation as replica counts increase. Horizontal scaling of stateless application instances cannot overcome a shared database or dependency bottleneck. Control aggregate concurrency, optimize database access, introduce suitable caching or partitioning, and select autoscaling signals that reflect useful capacity.

The header can become an identity-spoofing vulnerability if callers can reach the service directly or inject an untrusted value. Establish a trusted gateway-to-service channel, strip client-supplied identity headers, and authenticate the component asserting identity. Alternatively, propagate a properly scoped signed token and validate its issuer, audience, signature, and authorization claims at the receiving service.

Use an expand-and-contract migration that keeps the database compatible with both application versions during rollout. First add a compatible nullable column or safe default, deploy code that handles both representations, and backfill existing records. Enforce the final non-null constraint only after data is complete and all active writers satisfy the new requirement.

Coordinate scheduling through a single designated worker, a distributed lease, or a durable job queue with competing consumers. A distributed lock reduces concurrent execution but does not eliminate duplicate effects during crashes, lease expiry, or network partitions. Protect billing with durable idempotency keys and database-enforced state transitions; use fencing tokens where stale lock holders could corrupt shared state.

Inspect span boundaries and determine whether the unexplained time occurs before the downstream call, during connection acquisition, or after the response. Investigate thread-pool queues, serialization, authentication filters, database access, connection waits, and uninstrumented work. Add targeted spans and correlate them with thread dumps and metrics rather than assuming downstream execution time equals total client-call latency.

Enforce admission control and rate limits based on the downstream system's sustainable capacity rather than accepting unlimited concurrent calls. Queue durable asynchronous work where business requirements permit, with bounded backlog, prioritization, and explicit retry or expiry policies. For synchronous requests, apply backpressure and return appropriate overload responses; use caching or batching only when they preserve correctness.

Use a trusted identity provider or authorization server to issue appropriately scoped tokens, with each resource service enforcing its own authorization rules. Validate token signatures, issuer, audience, expiration, and permissions at trust boundaries; use service identities and suitable credentials for machine-to-machine communication. Centralize identity and policy management where useful, but preserve domain-specific authorization, key rotation, least privilege, auditability, and resilience to identity-provider outages.