Design a system to reduce large client-side experiment payload size

WHAT THIS TESTS: Whether you understand evaluation locality, payload compression, and the availability-consistency tradeoff in large-scale feature flag systems. Interviewers want to see you move complexity away from the client, minimize bytes transferred, and keep evaluation latency low without creating a hard dependency on a central control plane at startup.

A GOOD ANSWER COVERS: First, server-side or edge pre-evaluation so the client downloads only its specific variant assignments rather than the full rule set. Second, compact representations such as bucketing indexes, Bloom filters, or hashed variant maps that replace verbose JSON configurations. Third, lazy loading where noncritical experiments fetch after startup or on first use instead of blocking launch. Fourth, horizontal scaling of read nodes and stale-while-revalidate caching so the edge can answer without hitting the control plane on every request. Fifth, segmentation strategies that group users into buckets server-side to avoid shipping segment definitions to the client. Sixth, archiving short-lived experiments quickly so the active set stays small and the payload does not grow unbounded over time.

COMMON WRONG ANSWERS: Proposing to gzip the JSON blob without reducing semantic size, which still requires parsing and does not fix startup latency. Suggesting the client evaluate every flag against the full configuration locally, which leaks PII and bloats memory. Recommending real-time synchronous fetches at app startup, which adds network latency and creates a hard dependency on the control plane. Proposing strict consistency across all nodes, which sacrifices availability and slows rollouts. Splitting the payload by user segment on the client without solving the evaluation problem, which merely shifts complexity and can expose targeting rules.

LIKELY FOLLOW-UPS: How do you handle offline mode or intermittent connectivity? What happens when an experiment definition changes mid-session? How do you ensure a consistent user experience if edge nodes cache different versions? How would you measure payload reduction and its impact on startup time? How do you prevent flicker or variant jumping when cached assignments expire?

ONE CONCRETE EXAMPLE: A mobile app with 500 concurrent experiments reduces its startup payload from 800 KB of raw JSON to 4 KB by moving evaluation to a regional edge node. The edge node uses a user ID hash to look up the user's bucket in a compact index and returns a flat map of flag keys to variant strings. Critical flags are inlined into the initial 4 KB response while noncritical flags are fetched lazily after the home screen renders. The edge cache refreshes every 30 seconds with stale-while-revalidate, keeping p99 evaluation latency under 10 milliseconds.

Source: docs.getunleash.io