Skip to content

EYJ

Here is a complete, mock interview simulation based on our discussion. It features tough, realistic interviewer follow-up questions designed to test the depth of your knowledge, along with the ideal responses you should give.

🎭 Part 1: The Mock Interview Simulation## 🎙️ Interviewer Scenario

“You claim that for a 50k Requests Per Second (RPS) system, you can use a preStop lifecycle hook with a sleep 5 command to prevent dropped packets during rolling deployments. Let's stress-test that idea.”

❓ Mock Follow-Up Question 1

"If you add a sleep 5 to your preStop hook, and your application takes an additional 10 seconds to drain its internal connection pools after receiving SIGTERM, what is the absolute minimum value you must configure for terminationGracePeriodSeconds in your Kubernetes pod spec? What happens if you leave it at the default 30 seconds versus setting it too low, say 12 seconds?"

💡 Ideal Response: "The absolute minimum value would be 15 seconds (5s sleep + 10s app draining), but realistically I would set it to 25 or 30 seconds to provide a safety buffer.

  • If set to 12 seconds: Kubernetes will aggressively cut off the pod before it finishes saving its state. The preStop hook takes 5 seconds, leaving only 7 seconds for the app to drain. Since the app needs 10 seconds, Kubernetes will forcefully issue a SIGKILL at the 12-second mark, instantly dropping active user transactions.
  • If left at the default 30 seconds: It will work perfectly. The total shutdown sequence takes 15 seconds, and as soon as the application process exits natively, Kubernetes removes the container immediately. It does not force the pod to wait around for the full 30 seconds."

❓ Mock Follow-Up Question 2

"At 50k RPS, you suggested using Tail-Based Sampling in your OpenTelemetry Collector tier to save only errors and slow requests. If a core downstream microservice undergoes a catastrophic failure and starts throwing 50,000 errors per second, your tail-based sampler will try to save 100% of those traces. How do you prevent your tracing backend (e.g., ClickHouse or Tempo) from crashing due to this sudden storage surge?"

💡 Ideal Response: "To protect the tracing backend from an anomaly or an 'error storm,' I would implement a two-layer safety valve inside the OpenTelemetry Collector configuration:

  1. Rate-Limiting Sampler: I would place a rate_limiting processor right after the tail-based sampling logic. This caps the absolute number of traces passed to the storage engine (e.g., maximum 2,000 traces per second), dropping excess error traces once the system is flooded.
  2. Adaptive Batching: I would configure the batch processor to hold spans in memory and flush them based on size constraints. If the storage layer experiences backpressure, the collector will drop data in memory rather than overwhelming the database and causing a cascading infrastructure failure."

❓ Mock Follow-Up Question 3

"You mentioned utilizing a multi-region Active-Active architecture for disaster recovery. In a system handling 50k RPS, how do you handle database replication across regions without running into split-brain scenarios or severe write latency caused by the speed of light limits between data centers?"

💡 Ideal Response: "At 50k RPS, synchronous cross-region database replication is impossible due to network latency overhead. To handle this, I would split the data layer strategy based on business requirements:

  • For Core Transactional Data (ACID): I would pin writes to a single 'Primary Cloud Region' and use asynchronous replication to the secondary disaster recovery region. If a user lands on the secondary region, their read request is served locally, but their write request is routed back over a cross-region backbone network to the primary database.
  • For High-Volume, Non-ACID Data: I would use a globally distributed NoSQL database like AWS DynamoDB (with Global Tables) or Apache Cassandra. These leverage Eventual Consistency and conflict resolution strategies like Last-Write-Wins (LWW) or CRDTs (Conflict-free Replicated Data Types) to safely merge concurrent cross-region updates without stopping the application."

⏱️ Part 2: Rapid-Fire Follow-Up Questions (By Topic)

Prepare for these short, sharp follow-up questions that interviewers use to verify if you truly understand the engineering trade-offs.

Topic A: JavaScript & Promises

  • Q: "In your Promise code example, if the first .then() throws a synchronous error, does the .finally() block still execute?"
  • A: Yes. .finally() is guaranteed to run regardless of whether the promise chain resolves successfully or rejects with an error.
  • Q: "If I return a rejected promise inside a .finally() block, what happens to the original resolved value from earlier in the chain?"
  • A: The original resolved value is lost. The promise chain immediately morphs into a rejected state, carrying the new error downward to the closest .catch().

Topic B: Infrastructure Scaling

  • Q: "Why choose a Layer 4 Load Balancer over a Layer 7 Load Balancer at the topmost edge of your network?"
  • A: Layer 4 operates at the transport layer (TCP/UDP) without looking at HTTP headers, cookies, or SSL certificates. This allows it to route packets with near-zero memory footprint, making it cheap and highly resilient against 50k RPS volumetric surges.
  • Q: "At 50k RPS, your Redis cache will experience high eviction rates. What eviction policy would you use?"
  • A: I would use allkeys-lru (Least Recently Used) or volatile-lru paired with strict programmatic TTLs, ensuring that predictable hot data stays in memory while stale data gets evicted gracefully under memory pressure.

Topic C: Data & Logs

  • Q: "Why can't we skip Kafka and write logs straight from FluentBit into ClickHouse?"
  • A: ClickHouse performs exceptionally well with large, batched writes, but it degrades significantly if subjected to millions of tiny, concurrent row inserts. Kafka acts as an ingestion buffer, protecting ClickHouse by allowing consumers to batch hundreds of thousands of logs into a single write operation.

To make the most of this prep, choose one of the Mock Follow-Up Questions above and try explaining the answer in your own words, or let me know which area you want to drill down on next.