Post Publishing: Where Image Upload Breaks
Typical post publishing works like this: the user selects a file, the app prepares the image for upload as a whole — decodes the full-size frame into memory, compresses it, and keeps the result until the server confirms.
While image upload is in progress, the feed waits for a response: the optimistic post hangs in the "sending" state, and the interface blocks repeated taps so that two duplicates don't go out. On a slow connection, the wait stretches into minutes.
Upload failure occurs predictably: the connection drops in the last third of the request body — and everything already transferred is lost.
There is no draft: the prepared frame lived in RAM and disappeared with it, while the retry queue responds to network errors but not to the app being closed or backgrounded.
Compression before upload runs on the same thread: the interface is unresponsive, and interrupting the process kills both the preparation and the post itself.
This repeats in every release because the logic is spread across screens: the post creation screen keeps state locally, upload is tied to its lifecycle, and the data layer knows nothing about an unfinished post publication.
Any screen refactoring means losing the draft; updating the media picker library means a new failure on devices where there isn't enough memory for the full-size frame and the system kills the process.
We break down how this is addressed: chunked image preparation, a local queue with an idempotent key, and resumable upload after a drop — this way the post survives both network loss and app restart.
What Managed Media Upload in the App Provides
Managed media upload is a separate layer between the interface and storage: an upload queue, a local cache, and retry rules.
It separates the moment a post is sent from the moment the file actually lands in storage, and it is precisely this layer that determines whether the user perceives the app as fast.
Interface Responsiveness When Uploading
The post appears in the feed immediately — from a local copy — while the image uploads in the background.
Interface responsiveness does not depend on network speed or image size: the screen isn't blocked, progress is visible on the thumbnail, and the app can be minimized or you can navigate to another screen. The upload queue keeps working and synchronizes state when the connection returns.
Queue Resilience on a Weak Connection
The file is transferred in chunks with checksums: an interrupted session resumes from the last confirmed chunk, not from scratch. Retries use increasing delay and a cap on the number of attempts — the app doesn't saturate the connection or drain the battery in the subway.
Media size is reduced before upload: re-encoding to WebP and stripping service metadata reduce image weight by 2-4x with no visible quality loss, so the same connection delivers noticeably more posts.
The share of failed uploads on unstable networks drops to single-digit percentages, and the server side stops accepting the same files repeatedly — media archive volume grows in proportion to the number of posts, not the number of attempts.
Publishing Posts: Image Compression and Delivery Options
The trade-off here is always the same: where to cut quality, who pays for it with time, and what load the servers take. Below are four approaches that teams actually choose between when publishing posts.
| Option | When It Fits | Limitations |
|---|---|---|
| Compression on the device | High posting frequency, weak connections | Quality depends on the device; size headroom is needed |
| Original to the server, processing there | Guaranteed image quality | Slow publishing, peak load on servers |
| Hybrid: preview from the client, original in the background | Main feed scenario | Two phases; upload completion and synchronization are needed |
| Deferred queue processing | Batches of images, bulk uploads | Delay before the finished variant appears |
Compression on the Device
The client brings the frame to a reasonable size along the long edge, converts it to a modern lossy format, and strips metadata — the file becomes several times smaller with visually the same image.
This saves user traffic and offloads the ingestion side, but quality stops being predictable: different devices process it differently, and a weak phone produces a noticeably softer picture.
Server-Side Processing and Previews
The server accepts the original, cuts it into size sets for the feed preview, full-screen view, and card, and distributes them across the delivery network.
The feed loads the lightweight preview, the full frame is pulled on demand — switching between screens remains instant, and image quality is the same for everyone. The downside is the processing queue, which must be kept under control and be replayable on failure.
Work Stages: Audit, Design, Configuration, Handover
We start by analyzing how media currently gets into the app: where the image is prepared, in what form it goes to the server, and what happens when the connection drops. This is the baseline — without it, any optimization turns into guesswork.
Audit of the Current Upload Flow
- We map the current publishing path: file preparation, transfer, server response, and the preview appearing in the feed.
- We measure bottlenecks — the size of the uploaded file, time to preview display, and the share of failed uploads on a weak network.
- We document constraints: access rights, storage volumes, and content moderation requirements.
Design Approval and Device Testing
- We design the storage scheme: where compression is performed, which image variants are served for different screens, and what remains in the local cache.
- We configure compression: quality and format are selected for the content type, orientation and metadata are aligned automatically, and size is kept reasonable with no visible quality loss.
- We implement the upload queue: retries on interruption, background upload completion, and a clear publication status in the interface.
- We test on devices — weak network, minimized app, screen rotation, and low memory.
The outcome is a working publishing path, documentation on the scheme and compression settings, a trained team, and a checklist for new releases.
Schemes, Storage Policies, and Procedures as Deliverables
After release, the client's team retains not only the source code but also schemes, configurations, and procedures that let the app live and evolve without us.
We keep them next to the code so compression parameters change through review rather than manually on the server, and the on-call engineer understands the media flow from a single page.
Schemes and Configurations
- Media flow scheme: from file selection in the interface to the post appearing — with compression points, preview generation, and retry upload without duplicating the publication.
- Compression profiles for scenarios: feed, full-screen view, avatar — with target quality and maximum file size for each.
- Upload queue configuration: number of concurrent tasks, response timeout, retry rules, and behavior when the connection drops.
- Media storage policy: lifetimes of the original and preview, cleanup of files not linked to a post, and deletion procedure on user request.
- Access scheme: roles and services with permission to read and delete objects, and the procedure for issuing temporary links.
Instructions for the Support Team
- Support procedure: how to read failed publication logs and distinguish a device compression failure from a storage error.
- List of common requests with ready-made investigation steps: image didn't upload, preview differs from the post, publication was sent twice.
- Procedure for editing compression parameters: where to change them, how to test on a sample image set, and how to revert to previous values.
Case Study: Cut Failed Uploads by Threefold
The client is a mobile app for a classifieds service: the user publishes a post with 4–8 photos directly from their phone, while on the move and on an unstable network.
The original scenario uploaded frames at full resolution in a single request, and the server resized them synchronously — if the connection dropped, the upload started from scratch.
The metric was calculated from events in Sentry: each attempt is logged with a result code and the stage at which it was interrupted.
Before
The share of failed uploads held at 21%: every fifth post with photos was re-sent by the user, and some abandoned it halfway. Feed response time after publication reached 6 seconds — the screen waited while the server prepared derived sizes.
The media archive grew without limits: retries spawned duplicates of originals, and storage doubled in about a year.
After
After implementation, compression moved to the device: the frame is reduced along the long edge before upload, and the preview appears in the feed immediately — the interface doesn't wait for the server response.
The upload is split into parts and resumes from the point of interruption, so the share of failed uploads fell to 7% — three times lower.
Feed response time dropped to 1–2 seconds, and the media archive policy keeps the original for 30 days and stores only derived versions — storage volume stopped growing with the same traffic.
How Does Client-Side Compression Differ from Server-Side Compression?
Client-side compression is reducing the long edge and re-encoding the image before upload: the device sends an already prepared file to the network, without metadata and extra pixels.
Bandwidth consumption drops several times, the post goes out even on a weak connection, and the server side receives a stream with predictable size. The price is that the result depends on the device: on a weak phone, re-encoding takes longer and produces artifacts.
Server-side compression is accepting the original and preparing all derived versions on the service side: thumbnails, variants for different screen densities, and re-encoding into current formats.
Processing rules change without releasing a new app version, and quality comes out the same on all devices. The limitation is that the original reaches the server in full, and the server load grows for ingestion, decoding, and storage of originals.
The choice is a trade-off between bandwidth consumption, image quality, and backend processing:
| Approach | When to Choose | Limitations |
|---|---|---|
| Client-side compression | Weak connection, mobile traffic, large camera photos | Quality and speed depend on the device; the original is lost |
| Server-side compression | Unified processing rules and stable quality are needed | Higher user bandwidth consumption; increased ingestion and storage load |
| Hybrid scheme | Both fast display and original preservation are needed | More complex logic: two passes and image version coordination |
On a weak connection, client-side compression with a long-edge limit and background upload of the original wins — the user sees their post faster.
On a stable connection, server-side is preferred: unified processing rules are easier to maintain, and quality doesn't depend on the device fleet.
Common Technical Concerns and Limitations
Publishing a post with an image is not a single request but a chain: file selection, compression, queueing, upload, rendering. Failures at each step are reproducible, which means they can be closed in advance — before the user writes "it didn't upload".
Below are answers to what most often comes up when analyzing such a scheme.
What happens if the user sends the post twice?
Each upload is assigned an operation identifier, and the server stores its result. A repeated request with the same key does not create a second post but returns the already created one — this covers both a double tap on the button and a retry after an interruption.
How does upload behave on a weak connection?
The file is split into parts and uploaded resumably: after a drop, the upload continues from the last confirmed part, not from scratch. Compression happens on the device before upload, so several times less data goes over the network.
Where do originals and previews go?
The original and reduced copies are stored separately, and the preview is served from cache at the network edge. A scheduled storage policy removes unused versions, and deleting a post clears both the original and derived versions.
Are there limitations on the device side?
Yes: different capture formats, different amounts of available memory, and aggressive background process termination on iOS and Android. That's why compression is streamed, and the upload queue is restored after the app restarts.
Let's Discuss Your Task and Come Back with a Plan
To come back with a task estimate and work plan rather than general promises, we need to understand how post publishing works in your product: where the image comes from, what quality is considered sufficient, and what happens when the connection drops.
On our side, we clarify what is already implemented, what remains to be built, and where the bottlenecks are in the current architecture.
Next are what we'll need from you and what we check ourselves. It's usually the discrepancy in these points that turns a task from "finish the screen" into "rewrite half the upload".
- What already exists: the current app code, repository access, and mockups of the post creation screen — without this, the estimate turns into assumptions.
- Publishing scenarios: where the image comes from (gallery, camera, sharing from another app), how many posts go out at once, and whether an upload queue is needed.
- Requirements for the result: target file size, behavior on a weak network, output formats, and what the user sees while upload is in progress.
- What we clarify ourselves: compression on the device, resumable upload after network loss, and interface responsiveness on a slow connection.
- What we'll come back with: a task estimate by stages, a work plan with delivery points, and a list of risks.
- Further along the cycle: app support after launch and documentation handover — schemes, build and release procedures, and instructions for your team.
Describe the task in free form — we'll come back with an estimate and work plan.