Short answer: for mobile image payloads, resize before compression to the rendered bounds, then measure moderation coverage and delivery bytes as separate SLO signals.
The page usually arrives after the damage. A logistics driver opens a shipment photo on a weak connection, the thumbnail spins, and our delivery alert fires for elevated p95 image latency. The on-call sees retries, a queue that is technically healthy, and a sudden rise in abandoned scans.
I start at that alert and walk backward. The image was uploaded at 4032x3024, sent through a compressor, and only then reduced for a 320px card. Compression saved work on the wrong representation. The moderation service also saw a different crop from the one shown in search, so its coverage number looked fine while unsafe labels escaped the UI. That meant the queue had green health checks while the user-facing contract was already broken: the bytes were too large for the radio link, and the pixels we reviewed were not the pixels we served. The fix was a pipeline change, not a larger worker pool, because more workers would only process the wrong derivative faster.
1. What should mobile teams resize before compression for image payloads?
A payload should match the pixels a device will display. Keep the original in durable storage, derive a bounded working image, and compress that derivative. Width and height limits are easier to reason about than a vague quality knob: they cap decode memory, transfer size, and the amount of content moderation must inspect.
The bound should come from layout contracts. A list tile, a detail view, and an offline export need different derivatives. Do not make the client guess. Include dimensions and a representation identifier in metadata so a cache key cannot accidentally serve a four-megapixel image to a 320px slot.
Measure twice.
2. How should mobile image payloads, resize order, and compression affect moderation coverage?
Treat the displayed derivative as a first-class moderation input. Resize with a high-quality filter, preserve orientation from EXIF before rasterizing, and send the exact derivative (or a cryptographically linked version) to the moderation queue. Compression follows resizing because the encoder then spends bits on pixels that survive the crop.
Coverage is a ratio, not a feeling:
type Asset struct {
OriginalID string
VariantID string
Width int
Height int
Bytes int64
Moderated bool
}
func eligibleForSearch(a Asset, displayWidth int) bool {
return a.VariantID != "" &&
a.Width <= displayWidth &&
a.Bytes > 0 &&
a.Moderated
}
Alert on the gap between variants_published_total and variants_moderated_total, grouped by derivative type. A byte reduction can be a success while coverage is a regression. Keep those alerts independent, or an apparent bandwidth win will hide a policy failure.
2. Make the pipeline observable and test the ugly inputs
Record original dimensions, output dimensions, encoder, quality setting, bytes, decode time, and moderation decision ID. Add a trace span around orientation, resize, encode, upload, and queue publish. The useful dashboard has at least three lines: bytes per delivered variant, p95 decode-plus-transfer time, and percentage of searchable variants with a decision.
On one incident, a 12% drop in average bytes looked healthy until a percentile view showed the largest depot photos still timing out. The median was telling the wrong story. SRE dashboards should expose cohorts by device class and connection hint, not just an all-traffic average.
Build a fixture set from real shape categories without retaining sensitive content: panoramic loading-bay shots, tiny receipts, rotated phone images, transparent PNG logos, and near-maximum upload dimensions. Verify that a resize never enlarges a small source, that metadata orientation is applied once, and that the moderation record points to the served variant.
Use golden dimensions and byte ceilings in CI. Then run a canary that compares delivery latency and moderation coverage against the previous derivative policy. I am not sure a single quality value will hold across every handset and carrier; your mileage will vary, so keep the encoder setting configurable and let evidence move it.
3. Which fallback protects coverage when the byte contract fails?
A slow connection is not permission to ship an unreviewed image. If a requested variant cannot meet its byte ceiling, serve a smaller bounded derivative that already has a moderation decision, or withhold it from search until review completes. This is a product trade-off: a slightly blurrier thumbnail is preferable to an unreviewed one in a driver-facing workflow.
The catch is that this policy is unsuitable for archival downloads, where fidelity is the requirement. Stick with the original or a lossless derivative for legal evidence and export jobs, and keep those paths out of the mobile search SLO.
Keep the old and new derivative recipes addressable for at least one release window. A feature flag can route a depot, device cohort, or percentage of traffic while you compare bytes, p95 latency, cache hit rate, and moderation coverage. Roll back the recipe when a guardrail moves, not when one noisy request appears.
This closes the loop to the page that started the investigation. The early signal is a missing moderation decision or a variant breaching its size budget; the late signal is a driver waiting on a spinner. Instrument the boundary, resize before compression, and make the served pixels the reviewed pixels.
Top comments (0)