FDEBench Join us live

Q
3 / 159

Cost & scale

An integration protocol currently requires a handshake to establish a session, after which every subsequent message must reach the same server instance. Explain the scaling problems and how you would redesign it.

question bank FDEBench bank

01
Ask

What a strong candidate asks first

Before designing anything. Skipping this is the most common way the round is lost.

  • How long does a session live — seconds or hours? Long sessions make affinity much worse.
  • Is any of the session state genuinely necessary, or is it just cached negotiation?
  • Are there streaming or subscription use cases that need a persistent connection anyway?
  • How many existing clients assume the handshake? That sets the migration cost.

02
Rubric

What earns the points

6 criteria, 100 points total. Scored independently, partial credit allowed.

Sees each session pins a server 20 pts

Identifies that state living in one process forces the load balancer to pin the client, and that affinity is the root constraint.

If you miss it You listed symptoms without naming the cause. Session state in the process means the router must send every subsequent request back to that same instance — everything else follows from that.
Lists what pinning costs 20 pts

Enumerates at least three real consequences: uneven load from long-lived unequal sessions, autoscaling that cannot shed work, deploys that drop every session on an instance, and sticky routing as an operational burden.

If you miss it Say what affinity actually costs you. Load skews because sessions are long and unequal, scale-in kills live sessions, and every rolling deploy is a mass disconnect.
Self-contained requests 20 pts

Makes each request self-contained so any instance can serve it, and states the payoff explicitly: round-robin routing, deploys without drain, working autoscaling, disposable instances.

If you miss it You removed the handshake without saying what each request now carries. Self-contained requests are the whole point — spell out what moves into the request and what that buys operationally.
Shared store for lasting state 15 pts

Moves state that genuinely must persist into a shared store keyed by a client token, so it is shared rather than pinned — and distinguishes that from state that can simply be re-sent.

If you miss it Some state has to survive between requests. Say where it goes — a shared store keyed by a token the client presents — rather than implying stateless means stateless everywhere.
Admits what gets worse 15 pts

Names what gets worse: larger requests, repeated per-request auth and validation, a shared store now on the hot path, and a harder story for genuinely streaming subscriptions.

If you miss it You presented this as free. Requests get bigger, validation repeats on every call, and you have introduced a shared store that is now a dependency on every request.
Versions it and runs both modes 10 pts

Versions the protocol and supports both modes during the transition, since existing clients assume the handshake, and keeps a persistent transport available for streaming.

If you miss it You changed a protocol every existing client depends on with no migration. Version it, run both modes, and give clients a deprecation window.

03
Flags

Red flags

Reported separately, not subtracted — this is the "what would have ended the interview" note.

  • Proposes sticky sessions as the fix rather than the problem.
  • Removes the session without saying where its state went.
  • No versioning or dual-mode period for existing clients.

—