System Design Interview Questions for Senior Java Developers

Use a saga with explicit state transitions and durable progress tracking rather than assuming one ACID transaction spans all services. Reserve inventory, authorize payment, and initiate shipping through coordinated steps with idempotent handlers. Define compensations such as releasing inventory or voiding payment authorization when later steps fail. Some actions cannot be perfectly reversed, so support reconciliation, manual intervention, and clear terminal states.

Make seat allocation authoritative in transactional storage using conditional updates or unique constraints that prevent conflicting reservations. Introduce short-lived reservations with explicit expiry and payment confirmation states. Use admission control or queues to limit contention, while keeping database concurrency controls as the final correctness boundary. Handle expired reservations, payment uncertainty, retries, and delayed confirmations without assigning the same seat twice.

Replication lag allows a replica to return older data even after the primary commits successfully. Route dependent reads to the primary, or use a replication-position mechanism to wait until a replica has applied the required change. Apply stronger consistency only where necessary because primary reads or replica waiting can reduce scalability. For example, read the updated profile from the primary immediately after saving it, while allowing eventual consistency for unrelated browsing.

Define durability, recovery point, recovery time, and consistency requirements before selecting active-passive or active-active deployment. Use a storage replication and commit strategy whose acknowledged-write guarantees match the required data-loss tolerance. Control write leadership and fencing during failover to prevent conflicting writers and split-brain behavior. Strong cross-region durability may increase write latency or reduce write availability during network partitions, so expose those tradeoffs explicitly.

The system is experiencing synchronized cache misses that create a sudden surge of database reads. Add expiration jitter, request coalescing or single-flight loading, and bounded refresh concurrency. For very hot data, consider proactive refresh or carefully designed stale-while-revalidate behavior. Protect the database with concurrency limits and measure whether stale responses are acceptable for each data category.

Define an end-to-end request deadline and allocate bounded time budgets to downstream operations. Use connection and response timeouts, concurrency limits, and cancellation where supported. Retry only suitable failures with bounded attempts, jittered backoff, and enough remaining deadline, avoiding retries at every service layer. Measure tail latency and dependency saturation because parallel calls can amplify the probability of encountering a slow dependency.

Partition events by a stable customer identifier so events for one customer are routed to the same ordered partition. Process records sequentially for that partition when business correctness requires strict order. Different customers can be processed in parallel, but a very active customer may create a hot partition. Handle producer ordering, retries, replay, and state versioning because partition ordering alone does not guarantee correct business state transitions.

Publish trusted public verification keys through a controlled key-distribution mechanism and validate signed access tokens locally at resource services. Validate issuer, audience, expiry, algorithm, and applicable permissions rather than trusting signature verification alone. Keep coarse-grained identity claims in tokens while evaluating resource-specific authorization against current domain rules. Plan key rotation, token revocation requirements, and policy changes because locally verified JWTs may remain valid until expiration.

Treat the payment outcome as unknown rather than immediately marking it failed or issuing another charge. Persist the operation identifier and query the provider using its transaction reference or idempotency key. Use provider webhooks and reconciliation jobs to converge the local payment state with the external result. Model states such as PENDING, SUCCEEDED, FAILED, and REQUIRES_REVIEW, and avoid repeating non-idempotent financial operations.

Define the collaboration consistency model and choose operational transformation or a suitable CRDT approach for concurrent edits. Assign document versions or operation identifiers and persist an ordered or mergeable change history. Use WebSockets for low-latency updates while supporting reconnect, replay, and snapshot recovery. Consider offline edits, authorization changes, conflict semantics, and storage compaction rather than relying on message delivery order alone.

Measure active database connections, connection wait time, executor queue depth, and request arrival rate to identify the actual bottleneck. Apply bounded queues, admission control, and concurrency limits aligned with database capacity. Optimize transaction duration and reduce blocking database work before increasing connection counts. Virtual threads can reduce the cost of blocked Java threads but do not increase database capacity or eliminate downstream contention.

Select a shard key using access patterns, tenant distribution, data locality, and expected growth. Backfill data incrementally while capturing ongoing changes through CDC or a controlled dual-write migration process. Validate record counts, checksums, routing correctness, and consistency before moving read and write ownership. Plan rollback, cross-shard queries, unique identifiers, and hot-shard mitigation because data movement is only one part of sharding.

Trace the dependency path to determine whether checkout waits on recommendation calls, exhausts shared resources, or propagates their exceptions. Introduce strict timeouts, circuit breakers, and resource isolation around the optional dependency. Return checkout results without recommendations when that dependency is unavailable, preserving critical business behavior. Test the fallback under slow responses, connection exhaustion, and partial network failures rather than only immediate exceptions.

Use authenticated upload sessions and direct multipart or chunked uploads to object storage to avoid routing large files through application memory. Track upload ownership, part completion, integrity checks, and finalization using durable metadata. Keep uploaded objects quarantined until scanning and validation succeed, then authorize access to approved files. Use short-lived signed download URLs or an authenticated download proxy, and enforce file-size, retention, and tenant-isolation policies.

Establish tenant identity from trusted authentication context and propagate it through authenticated service communication. Enforce tenant-scoped authorization and queries at service and data-access boundaries, not only in controller filters. Use composite keys or tenant-aware constraints where needed to prevent cross-tenant relationships and updates. Test direct object references, asynchronous jobs, cache keys, and administrative operations for tenant-data leakage.

Measure consumer lag by partition, processing latency, partition count, broker health, and downstream storage capacity. Additional consumers in the same group can improve parallelism only up to the available partition count and other bottlenecks. Optimize batching, processing cost, and downstream writes before scaling consumers blindly. If lag is concentrated in one hot partition, reconsider partition-key distribution or workload isolation while preserving required ordering.

A strictly enforced global quota requires coordination that can add cross-region latency or reduce availability during partitions. For near-global limits, allocate regional token budgets and periodically reconcile usage against a central quota. Bound possible overshoot through conservative allocations, short reconciliation intervals, and reserved capacity. Use stronger centralized enforcement for operations where exceeding the quota is unacceptable, and document the availability tradeoff.

Treat the rename as a breaking change and introduce the new field without immediately removing the old one. Support a documented transition period with compatibility adapters or explicit API versioning where necessary. Use consumer-driven contract tests and schema compatibility checks for affected HTTP and event consumers. Measure old-field usage and remove compatibility only after clients and replay requirements have been addressed.

Compare before-and-after traces, latency histograms, deployment changes, and dependency metrics rather than relying on averages. Inspect slow database queries, connection waits, thread contention, GC pauses, retries, and external calls for correlation with tail requests. Reproduce the problem under representative concurrency and isolate the regression using controlled comparisons. Rollback when customer impact is severe, then verify the root cause with evidence before redeploying a fix.

Use durable transactional storage with explicit transaction states, immutable audit records, unique operation identifiers, and database-enforced financial invariants. Integrate asynchronous consumers through an outbox and idempotent processing, with reconciliation for uncertain external outcomes. Define recovery objectives and choose replication, backup, and failover mechanisms that satisfy acknowledged-write durability requirements. Validate the design through concurrency tests, duplicate-delivery tests, fault injection, restore drills, and end-to-end ledger reconciliation.