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

Tests edge evaluation and payload compression. Use server-side pre-evaluation or edge nodes sending only assigned variants; compact bucketing indexes or Bloom filters; lazy-load noncritical experiments. Never do full client-side evaluation of every flag rule.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
Which strategy most effectively reduces client-side experiment payload size while maintaining low startup latency in a large-scale system?
- a.Partition the payload by user segment on the client and download all active experiment rules for that segment
- b.Compress the full JSON configuration with gzip and evaluate all flags client-side on startup
- c.Move evaluation to edge nodes, return a compact per-user variant map, and lazy-load noncritical experimentsCorrect
- d.Require the client to fetch the latest experiment definitions synchronously from the control plane before rendering
Why? this is the answer
Edge pre-evaluation minimizes the payload by sending only assigned variants rather than full rule sets, and lazy loading defers noncritical data; simply gzipping JSON (option B) still forces the client to parse and evaluate a large configuration, failing to address startup latency or memory bloat.
Just read this? Test yourself on what you have been reading.
Read the original → docs.getunleash.io
- #experimentation
- #feature-flags
- #system-design
- #edge-computing
- #performance
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on experimentation — each one lists the topics its interview covers.
See open roles