The dock map polls the full station feed every 60 seconds from every open browser. Product wants it on 5,000 concurrent screens for a launch. The platform lead asked for a number before approving: what does the feed weigh as served, what does gzip do to it, and how many gigabytes a day is full polling at that scale? The answer decides whether the launch ships with polling, gzip, or a change to pushing deltas.
Measure the docking-station file exactly as it is served and report:
feed_bytes — the size of the file in bytes, as served, unchangedfeed_bytes_gzip — its size after gzip at the default level (6)daily_gb_uncompressed — bytes transferred per day if 5,000 clients each fetch the uncompressed feed every 60 seconds, in GB (1 GB = 10⁹ bytes), 1 decimalDownload the file and measure the bytes you received. Do not re-serialise it: a pretty-printed or minified copy is a different file with a different size, and the number the platform lead needs is the one on the wire.
These are where the teaching is. Read them twice.
Sizing transfer from a measured payload is the first step of any live-layer design review, and the number is what turns 'we should push deltas' from an opinion into a requirement.
Work the problem in whatever tool you like, then enter the answers here.
feed_bytesfeed_bytes_gzipdaily_gb_uncompressed3 scored, 0 informational
Feed size as served
30%Feed size after gzip
30%Daily transfer at 5,000 clients polling uncompressed
40%