1,000×
more bytes than the screen uses
At 250 requests a second, 2 MB responses mean about 4 Gbit/s of egress and 2 GB/s of garbage, against 4 Mbit/s and 5 MB/s for one page.
Is one big response always better?
Bad: Ship it all
500 orders to skip one page call is 2 s to save 60 ms.
Good: Bundle what pays
Bundle extras under bandwidth × RTT, about 60 KB on 4G.
SELECT * is a promise about the future
It means “whatever columns this table has, forever”. Add a 50 KB description_html next year, and every list query silently starts shipping it.
Detect it: a fast query inside a slow request
The query takes 45 ms and mapping 500 orders 200 ms, then the phone downloads 2 MB for 2 s. Server dashboards say 245 ms.
Fetch only what the screen needs
- Name columns; never SELECT * on hot paths
- Filter, sort, sum and LIMIT in the query
- One keyset page through a covering index
- Views or field masks that reach the query
25,000
requests a minute, up from about 2,000
In Azure’s test, an endpoint pulled over 280 KB into the app to return a 14-byte total. Summing in SQL cut the read to 53 bytes.
You add a DynamoDB ProjectionExpression for 5 of 40 attributes. Does the bill drop?
The catch
No. Reads are charged on item size, in 4 KB steps. To cut capacity, shrink the item.
Say it like this
Decide what the screen needs as early as possible, ideally in the database. Named columns, filter, sort and limit in the query, one page at a time, details on demand.