Layer 3 · Go deeper · 7 min
Go deeper
Size it, build it, then make the calls an interviewer will push you on.
Back of the envelope
Size it up
Tap through each step of the arithmetic.
How often does a slightly flaky probe eject a healthy pod?
Why does pulling overloaded servers out make things worse?
Build-up · 6 steps
Watch a deep check empty the fleet
Twenty pods, both probes running SELECT 1, and a primary that takes 60 seconds to fail over. Then the same failover with shallow checks.
Step 1 of 6
Both probes run SELECT 1
Twenty orders-api pods query the shared database in readiness (every 5 s, 2 failures) and liveness (every 10 s, 3 failures). It feels thorough: a pod that can’t reach its database seems useless.
4 interview moments
You’re the candidate
The interviewer pushes on the hard parts. Pick an approach and see how it holds up.
Deep dive 1 of 4
Interviewer
“Your orders-api pods run SELECT 1 against the shared database in both liveness and readiness. What should each probe check?”
Your move. Pick an approach:
Deep dive 2 of 4
Interviewer
“Behind an ALB on default checks, a hung target gets about 6,500 requests before it is removed. What do you change?”
Each instance serves 100 requests a second. Defaults are a 30 s interval, a 5 s timeout and an unhealthy threshold of 2.
Your move. Pick an approach:
Deep dive 3 of 4
Interviewer
“A service needs more than 30 s to boot, and with default probes its pods restart before ever serving. What do you change?”
Your move. Pick an approach:
Deep dive 4 of 4
Interviewer
“Every rolling deploy drops a few requests per pod. Your app exits the moment it gets SIGTERM. What do you change?”
Your move. Pick an approach: