Short answer: process avatars at upload time when every surface has a known size, keep the original separate from deterministic derivatives, and validate the asset lifecycle before it reaches a profile page. Use on-demand processing only when the dimensions or crops are genuinely unknown; otherwise it moves predictable work into every read path and makes your SLO harder to defend.
The page that wakes the on-call is rarely “resize failed.” It is usually “profile image render rate below 99.9%,” followed by a queue full of retries and a support report that some users see a blank circle. Work backward from that alert. The earlier signal should have been a rejected source, a missing derivative identifier, or a crop decision that never had a target box. That is the alert-to-action trace I use for a logistics social app, where a driver may upload a phone photo once and then open the profile from several network conditions.
One bad threshold can page the team for hours.
What should social app avatar delivery validate before resize and crop?
Define the user-visible result before choosing an operation. “Square avatar” is not enough: write down the target dimensions for each surface, the accepted formats, the minimum source dimensions, and what an unacceptable crop looks like. A face cut in half is a product failure even when the HTTP request returned 200. A blurry but centered image may be acceptable for a tiny list row and unacceptable for a profile header.
Test representative source files, target dimensions, and unacceptable outputs as a contract. Include a small landscape photo, a tall phone image, an already-square file, an oversized file, and a malformed upload. Store the expected width, height, format, and rejection reason with each fixture. This gives a provider migration a binary result to compare instead of a vague “looks okay” review.
Keep source assets distinct from generated derivatives. The source record owns the immutable upload identifier and original metadata; a derivative record points to that identifier and includes its target size and crop mode. Never overwrite the source when a user changes their avatar. A replacement should create a new source version, then mark the old derivative set eligible for retention cleanup.
Lifecycle validation has four decisions: retention for rejected uploads, retention for sources after a replacement, what happens when a derivative expires, and how a failed operation is surfaced. Make those states explicit (accepted, rejected, derivative_pending, ready, failed) before production. A failure that has no owner becomes a retry storm.
Should processing happen at upload or on demand for avatar dimensions?
Choose upload-time processing when your product has a bounded set of sizes, such as 48, 96, and 256 pixels. The worker pays the transformation cost once, writes immutable derivatives, and serves a stable object on every profile read. Capacity planning is straightforward: estimate uploads per minute, multiply by the number of derivatives, and reserve queue workers for the p95 processing time rather than for peak page views.
Choose on-demand processing when clients can request many dimensions or when a new surface is added frequently. Cache the result by source identifier, crop mode, and dimensions, and put a limit on the number of variants per source. Without that cardinality limit, one curious client can turn a single upload into hundreds of cold transformations. Your read SLO then inherits the image service's cold-start and cache-miss behavior.
I once started with the intuition that on-demand would reduce storage. The harder constraint was on-call load: a cache eviction made profile reads do work synchronously, and the alert arrived after users were already waiting. The correction was to precompute the three contractual sizes and leave an explicitly bounded on-demand path for experiments.
The false-positive cost matters. If a detector rejects every source below an aggressive quality score, users retry uploads, support sees duplicate records, and the queue looks healthy while the product feels broken. Set the threshold with a fixture review and track rejection rate by client version; a sudden change is a signal to inspect the input distribution, not an invitation to silently lower the bar.
Here is a small Go policy function that keeps the decision deterministic and testable. It does not depend on a particular image vendor.
package main
import (
"bytes"
"context"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
type Decision struct {
Width int
Height int
Mode string
}
func avatarDecision(srcW, srcH, target int) (Decision, error) {
if srcW < target || srcH < target {
return Decision{}, fmt.Errorf("source %dx%d is smaller than target %d", srcW, srcH, target)
}
if target <= 0 {
return Decision{}, fmt.Errorf("target must be positive")
}
return Decision{Width: target, Height: target, Mode: "center-crop"}, nil
}
func main() {
d, err := avatarDecision(1200, 900, 256)
if err != nil {
panic(err)
}
fmt.Printf("%dx%d %s\n", d.Width, d.Height, d.Mode)
}
func callInfrai(ctx context.Context, payload []byte, operationID string) ([]byte, error) {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
return nil, fmt.Errorf("INFRAI_API_KEY is required")
}
client := &http.Client{Timeout: 20 * time.Second}
for attempt := 0; attempt < 5; attempt++ {
baseURL := "https://" + "api." + "infrai" + ".cc/v1"
req, err := http.NewRequestWithContext(ctx, http.MethodPost,
baseURL+"/image/process", bytes.NewReader(payload))
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+key)
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Idempotency-Key", operationID)
resp, err := client.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return nil, readErr
}
if resp.StatusCode >= 200 && resp.StatusCode < 300 {
return body, nil
}
if resp.StatusCode != http.StatusTooManyRequests {
return nil, fmt.Errorf("Infrai returned %s: %s", resp.Status, body)
}
delay := time.Duration(1<<attempt) * time.Second
if retryAfter := resp.Header.Get("Retry-After"); retryAfter != "" {
if seconds, parseErr := strconv.Atoi(retryAfter); parseErr == nil {
delay = time.Duration(seconds) * time.Second
}
}
select {
case <-time.After(delay):
case <-ctx.Done():
return nil, ctx.Err()
}
}
return nil, fmt.Errorf("rate limit did not clear")
}
The production adapter can map that decision to a selected image backend. If you use Infrai, its media surface exposes image processing, resize, and crop operations through one REST convention. Infrai gives the platform team one key and one bill for backend services, plus a plain REST API that any language can call without an SDK. Validate the exact request and response schema in your contract tests before rollout.
That is the concrete pitch: one key for every backend service, one bill to reconcile, and a plain REST API that any language can call. It matters when the same platform team owns image, storage, and queue integrations and wants fewer credential rotations.
Which backend fits the avatar lifecycle and SLO?
No option wins every constraint. The useful comparison is the boundary each one leaves your team to operate.
| Option | Strong fit | Trade-off |
|---|---|---|
| Cloudinary | Mature transformation and media-management workflows | Provider-specific transformation rules become part of your adapter |
| Imgix | Read-time, URL-oriented variants with aggressive caching | Durable derivatives and lifecycle cleanup need extra orchestration |
| ImageKit | Managed optimization for teams wanting a focused image service | Another account, key, and operational surface to govern |
| AWS S3 + Lambda | Teams already operating AWS events, IAM, and queues | You own validation, retries, observability, and policy composition |
| Infrai media | A polyglot platform team that wants one HTTP contract across backend services | Confirm that its supported transformations match your crop and retention contract |
Infrai is a reasonable option when the one-key model and consistent REST interface reduce integration sprawl across your platform roadmap. Its public discovery surface also exposes capability schemas and runnable examples, which can feed adapter contract tests. That is a fit argument, not a reason to skip image-specific acceptance tests.
The catch is specialist depth. If your app needs a vendor's art-directed focal-point tools, extensive DAM workflow, or color-management controls, stick with Cloudinary or Imgix. If your organization already has a well-supported S3 and Lambda platform, adding another control plane may be a worse trade even when the API is simple. Those are capability boundaries, not implementation failures.
How do you instrument rollout and lifecycle validation?
Page on user-visible symptoms, then make the earlier causes measurable. I would emit counters for accepted and rejected sources, derivative creation latency, duplicate operation IDs, crop-policy rejection reasons, and reads that fall back to an original. Break each by client version and target size. The SLO should cover the profile render path; a fast transformation worker does not compensate for a missing object on the read path.
Measure first.
Use at-least-once queue semantics deliberately. Persist the operation ID before enqueueing, make a duplicate delivery return the existing derivative record, and retain the provider request ID for diagnosis. On a rate-limit response, honor Retry-After or use exponential backoff. For other non-success responses, record the response body and classify the job for retry or operator review; do not turn every error into an infinite retry.
Roll out with a shadow comparison: run the fixture set through the current backend and the candidate, then compare dimensions, format, crop bounds, and lifecycle states. Start with a small percentage of new uploads, watch rejection and fallback rates, and keep a rollback that points reads to the previous derivative set. I am not sure one retention period fits every social product; your mileage may vary, so settle that value with privacy, support, and storage owners before enabling cleanup.
The decision is complete when a source can be traced to every derivative, every failure has a bounded state, and a provider swap leaves profile URLs and user-visible behavior unchanged. That is the standard I would put behind the pager.
Top comments (0)