Backend Interview: 15 In-Depth Questions

③ Quantified high-score answer

In production, I strictly prioritize "updating the database first, then deleting the cache." Deleting the cache first exposes a wide vulnerability window: concurrent read requests will miss the cache before the DB transaction commits, fetching stale records from MySQL and repopulating Redis for the entire TTL. Conversely, updating the DB first limits inconsistency to the brief window between transaction commit and cache eviction. To handle network-induced eviction failures, we decouple cache invalidation from synchronous application code by capturing MySQL Binlog mutations via Canal and publishing them to an MQ retry consumer. Accepting brief sub-second eventual consistency eliminates long-term dirty cache risks entirely.

③ Quantified high-score answer

We enforce three defensive rings: client-side deduplication, Redis distributed idempotency locks, and database unique constraints. When a client initiates a sensitive mutation, it generates a unique requestId. The backend interceptor executes `SET order:req:{requestId} 1 NX PX 3000`: failed lock acquisition directly returns "Duplicate request in progress", while successful acquisition enters the business transaction. The lock TTL defaults to 3 seconds—long enough to absorb network packet retransmissions while avoiding permanent deadlocks if nodes crash. Finally, a unique compound index on `(user_id, client_req_id)` in the order table serves as the unbreakable hard safety barrier against extreme race conditions.

③ Quantified high-score answer

For standard workloads, we rely on row-locked atomic SQL conditional updates: `UPDATE item_stock SET remain = remain - ? WHERE item_id = ? AND remain >= ?`, preventing overselling via InnoDB row locks. However, during flash sales where single-SKU traffic surges past 10k QPS, severe row-lock queuing will exhaust DB connection pools. We graduate to "Redis + Lua script atomic pre-deduction + asynchronous transactional MQ": the Lua script performs stock sufficiency validation and deduction atomically in single-threaded Redis, absorbing the initial traffic spike. Validated orders are then queued via transactional messages to MySQL. This scaled our single-item flash sale throughput from 700 QPS on MySQL to 12,000 QPS reliably, backed by scheduled delayed reconciliation jobs to release uncompleted reservations.

③ Quantified high-score answer

I diagnose slow queries via a disciplined sequence: "access type → key & key_len → Extra diagnostic states." First, inspect `type`: progressing from optimal `const`/`eq_ref` down to `ref`; dropping into `range` or `index`/`ALL` highlights severe indexing flaws. Next, verify `key` and compute `key_len` to determine exactly how many columns of a composite index were matched. Crucially, I examine Extra for `Using filesort` (failure to leverage index ordering, triggering buffer or disk sorting) and `Using temporary`. We resolve these by building covering indexes, appending order-by columns to the index tail, or rewriting deep offset queries into deferred joins to eliminate disk sorting and unindexed lookups.

③ Quantified high-score answer

The hazard of Executors lies in concealing unbounded resource limits. `newFixedThreadPool` defaults to an unbounded `LinkedBlockingQueue` (capacity of Integer.MAX_VALUE), which buffers infinite tasks until JVM heap exhaustion triggers an OOM. Conversely, `newCachedThreadPool` caps its maximum thread count at Integer.MAX_VALUE, endlessly spawning OS threads during sudden bursts until system PID limits or native memory are depleted. Production services must explicitly instantiate `ThreadPoolExecutor`: configuring bounded queues (e.g., ArrayBlockingQueue sized between 500 and 2000), tuning corePoolSize based on task characteristics (N+1 for CPU-bound, 2N or waiting-time-ratio scaling for I/O-bound), and adopting CallerRunsPolicy to apply natural backpressure on upstream callers.

③ Quantified high-score answer

I triage latency spikes using a three-tier funnel: "global telemetry → distributed trace → JVM runtime." First, check monitoring dashboards and APM tools (e.g., SkyWalking) to compare P99 latency, throughput, and error rates, isolating whether degradation is system-wide or confined to specific endpoints. Using TraceID, I identify whether latency accumulates in downstream RPCs, Redis contention, or database operations. If localized to application nodes, I inspect CPU load and active TCP connections. When CPU is low but response times skyrocket, it almost always indicates downstream I/O blocking or worker pool starvation. We take thread dumps via `jstack` to see if threads are parked in WAITING states. Once, an endpoint jumped from 80ms to 4s: distributed tracing pinned it on a 3rd-party logistics API with missing socket timeouts that starved our Web connection pool.

③ Quantified high-score answer

Premature lock expiration triggers two compounding catastrophes: concurrent threads penetrate the critical section destroying idempotency, and the delayed thread eventually executes `DEL`, inadvertently unlocking another worker's lock. Thus, releasing locks must execute a Lua script verifying client UUID ownership atomically. To resolve premature expiration, we utilize Redisson's Watchdog mechanism: upon lock acquisition, a Netty HashedWheelTimer initiates a background daemon that periodically renews the lock TTL every 10 seconds (one-third of lockWatchdogTimeout). If the holding instance crashes, heartbeat renewals terminate immediately, permitting Redis to expire the key automatically after 30 seconds, preventing cluster deadlocks while ensuring long-running transactions run safely.

③ Quantified high-score answer

Third-party services are unmanaged external dependencies; architectural defense centers on "fail-fast, bulkhead isolation, asynchronous decoupling, and graceful fallback." First, enforce strict timeout boundaries (e.g., connect: 1s, read: 2s), banning naive global retries. Second, apply circuit breakers (such as Sentinel or Resilience4j) using dedicated thread pool bulkheads to prevent stalled external requests from monopolizing Web container threads. If upstream error rates surpass 40%, the circuit trips immediately to serve cached defaults or queue requests to local persistent storage for deferred processing. When an external e-signature service suffered recurring 10-second stalls, our isolation and fallback safeguards reduced cascading failure rates across core approval pipelines to zero, preserving 120ms P99 response times.

③ Quantified high-score answer

At 20 million rows, we practice a cost-effective progression: "cold/hot archival first, horizontal sharding only when physically bottlenecked." In most applications, 95% of queries hit data generated within the last 90 days. We deploy offline scheduled jobs migrating completed orders older than six months into ClickHouse or historical archive tables, processing in primary-key-ranged batches (2,000 rows per batch with throttling sleeps to prevent replication lag), followed by table defragmentation. This keeps active tables under 5 million rows on 3-tier B+ Trees. If exponential growth demands sharding, we partition into 32 shards by `user_id` using ShardingSphere, while syncing MySQL Binlogs to Elasticsearch via Canal to power cross-partition multidimensional merchant queries.

③ Quantified high-score answer

Zero message loss demands a three-tier durability loop: producers activate confirmation protocols (e.g., RabbitMQ Publisher Confirm) with retry policies on NACK or timeout; brokers enforce disk persistence with synchronous flush and multi-replica quorum replication, eliminating data loss during leader crashes; consumers strictly disable auto-ACK, dispatching the manual receipt only after local database transactions commit. Idempotent consumption relies on consumer deduplication design: using a globally unique messageId, we insert a record into a consumption log table inside the primary business transaction. Database unique constraints instantly intercept duplicate deliveries caused by network retries, guaranteeing strict system consistency across millions of messages.

③ Quantified high-score answer

Our merchant order exports suffered frequent HTTP 504 timeouts on an 18-million-row dataset. EXPLAIN analysis showed the optimizer picked a single-column index on `created_at` instead of an optimal path, projecting 850,000 scanned rows with a catastrophic `Using filesort` that bloated query latency to 9.2 seconds. We engineered a covering composite index on `(merchant_id, created_at, status)`: this matched the leftmost equality filter, allowed range evaluation on dates, and leveraged physical B+ Tree ordering to eliminate sorting entirely. Scanned rows dropped from 850,000 to 260, filesort disappeared, P99 latency fell to 110ms, and insert throughput overhead remained below 2%, permanently eradicating export timeouts.

③ Quantified high-score answer

Under launch-eve pressure, the golden rule is: "contain blast radius, safeguard business commitments, and ban eleventh-hour rewrites." 24 hours prior to a major campaign, our product aggregation API peaked at only 400 QPS versus a 2,000 QPS target, bottlenecked by sequential downstream microservice calls with heavy calculations. Rather than attempting high-risk architectural overhauls, I implemented an emergency mitigation: adding an in-memory Guava cache with a short 10-second TTL to absorb 80% of redundant product reads, paired with circuit breakers that degraded secondary personalization widgets to static payloads. Throughput jumped instantly to 3,200 QPS. Following launch week, we refactored the pipeline cleanly into asynchronous non-blocking futures with CompletableFuture.

③ Quantified high-score answer

When facing production incidents, I enforce the iron rule: "stop the bleeding first, investigate root causes second, remediate systematically third." Following a user profile refactoring release, error rates surged to 5% within 3 minutes, triggering a P2 alert. Rather than attempting live server debugging, I executed an instant one-click rollback in our release console, restoring healthy baseline traffic in 70 seconds. Post-mitigation log analysis revealed legacy user accounts stored empty string avatar URLs that triggered deserialization NullPointerExceptions—an edge case missed in staging test suites. We introduced regression test coverage for legacy schema variations, integrated strict nullability gates in CI, and conducted a blameless post-mortem documenting defense protocols.

③ Quantified high-score answer

API backward compatibility is a non-negotiable architectural contract. We follow three engineering standards: First, response schemas are additive-only; deprecated fields remain preserved with defaults and never reused, while Enum deserializers must define an explicit `UNKNOWN` fallback to prevent mobile crashes. Second, new request parameters must never be mandatory; they require robust server-side defaults, or else necessitate overloaded endpoint paths. Third, disruptive breaking changes warrant versioned routing (e.g., `/v2/`). We instrument API gateway telemetry on deprecated routes; only when traffic drops below 0.05% and two deprecation warning cycles pass do we physically decommission endpoints, guaranteeing zero disruption across millions of installed app clients.