Avatar Upload Moderation: Review Three Sizes Before Publishing Derivative IDs

Compression reduces delivery bytes, but an avatar crop can change what a reviewer sees. For a B2B SaaS application, resolve that tension by treating moderation coverage as a publication requirement for the source and its three generated renditions. TL;DR: accept the upload privately, generate and review the exact outputs, persist their derivative IDs, and publish the complete approved set through one database transition. Keep operational metrics bounded; retain the evidence needed to explain that transition separately.

This design answers the practical Node.js and Express question: how should an avatar upload produce three sizes whose identifiers remain usable later? The interesting boundary is the moment those identifiers become visible to readers. A successful resize alone should not authorize publication.

What moderation should cover an avatar upload resized to three sizes?

Start with a release condition: the profile may reference a rendition set only when every required member belongs to the same accepted upload, matches the selected processing recipe, and has an acceptable review result under the selected policy. This is a proposed application contract. It does not assume that an image codec or a resize library provides moderation.

Define coverage explicitly. Reviewing the original can provide context that a tight crop removes; reviewing each output can expose what the application will actually display. Neither check should silently stand in for the other. If the chosen policy requires both, an accepted original and two accepted renditions still leave the set incomplete. A timeout is pending evidence, not an approval.

Keep the source and candidate renditions private while this condition is unresolved. That includes preview paths: attaching an unapproved URL to an otherwise private database record would defeat the publication boundary if that URL were publicly accessible. The serving layer should resolve only an approved profile pointer, with access rules applied independently of whether someone knows an object identifier.

Coverage comes first.

For a concrete design example, choose square outputs of 48, 96, and 192 pixels. These dimensions are illustrative requirements, not measured recommendations. A source-level review plus one review for each output creates four required review records per upload. Record the policy revision and the rendition identity on each result so that approval for one generated image cannot accidentally authorize a later replacement.

Derive the handler from the publication condition

In an Express application, separate request intake from publication. The upload handler should authenticate the caller, establish the tenant and profile being changed, enforce an input-size bound, and place the candidate in private storage. Treat the declared media type as a hint; acceptance should depend on the server's ability to decode the input within its configured resource limits. Return an operation identifier for asynchronous processing. Do not make a browser connection carry the lifetime of every review.

The MDN image-format guide describes differences in compression, transparency, animation, and format support. Those differences belong in the processing recipe. For example, explicitly decide whether animated input is rejected or reduced to a defined still image, and whether transparency survives in the selected output format. A recipe that leaves these choices implicit is difficult to review consistently. This article makes no claim that one output format supplies a universal quality or size advantage.

After intake, decode the accepted candidate, apply the defined orientation and crop rules, and generate all three compressed outputs. Review the exact stored outputs that could be served. If any bytes change afterward, create a new candidate and obtain the required review again. Otherwise, a previously approved artifact could become a different delivered image while retaining its approval record.

Persist a rendition record for each output with its own opaque derivative ID, the parent upload ID, dimensions, output media type, recipe revision, and storage reference. Keep review results attached to the corresponding candidate identities. IDs provide durable references; temporary delivery URLs are a separate concern. The application can resolve an approved ID into a serving location without rewriting the profile every time that location changes.

Now make publication transactional.

In one database transaction, verify the required records and move the profile's active rendition-set pointer to the accepted set. If verification fails, leave the existing approved avatar in place. Storage writes may already have occurred, so an incomplete candidate needs a cleanup path; a database transaction does not roll back an object store.

A retry introduces another boundary. Associate repeated submissions with an application-defined idempotency key scoped to the tenant and operation. Persist a profile revision or expected predecessor with the candidate, then check it during publication. Without that check, a slow earlier upload could finish after a later upload and replace the avatar the user most recently selected. A stale candidate can remain recorded without becoming active.

The following curl example illustrates a proposed private API contract, using a reserved example domain. It is not a documented endpoint of a public service. In this contract, the first request accepts a candidate; the second reads its state and returns the three derivative IDs only after publication. Replace the operation placeholder with the identifier returned by intake.

curl --request POST 'https://avatars.example.invalid/avatar-candidates' \ --header 'Authorization: Bearer REPLACE_WITH_TOKEN' \ --header 'Idempotency-Key: avatar-change-example-001' \ --form 'image=@avatar.png' curl --request GET 'https://avatars.example.invalid/avatar-operations/REPLACE_WITH_OPERATION_ID' \ --header 'Authorization: Bearer REPLACE_WITH_TOKEN' 

The handler's responsibility is consequently quite small: authorize, validate, stage, and acknowledge. The worker owns generation and evidence collection. The publication transaction owns visibility. Keeping these responsibilities explicit also makes failure recovery testable without treating a failed HTTP connection as proof that no work occurred.

Count evidence separately from metric labels

An operation ID is useful for investigating one candidate.

It is a poor default metric label because each new operation creates a new value. Keep candidate IDs, derivative IDs, tenant identifiers, and storage references in access-controlled event records or lookup tables. Use bounded dimensions for aggregate counters: stage, outcome, and rendition slot.

Consider an illustrative counter with 5 stages, 4 outcomes, and 3 rendition slots. Its Cartesian product has 60 possible label combinations before other dimensions are added. Adding a unique upload label makes the potential series count grow with uploads. The arithmetic is simple; the operational mistake is forgetting that every extra dimension multiplies the space. Some stage-slot pairs may never occur, so 60 is a bound for this example, not a measurement of a deployed system.

Retention deserves the same precision. Suppose, purely for planning, that 10,000 candidates arrive daily and each produces four evidence events averaging 600 bytes. Raw event volume is 24,000,000 bytes per day, or 720,000,000 bytes over 30 days. This excludes indexes, replication, compression, and storage overhead. It also excludes the images themselves. Change the assumptions before using the result for capacity planning.

Store less deliberately.

Sampling routine timing traces can reduce retained diagnostic volume, but sampling the evidence that establishes coverage would make some publication decisions impossible to reconstruct. Preserve the required decision record for the chosen retention period; sample routine successful traces independently. Keep rejected and failed operations diagnosable without logging image bodies, credentials, or full signed URLs. A reason category and a protected candidate reference usually support investigation with less duplicated sensitive material.

Compare review strategies after defining the boundary

The useful comparison is coverage, not a product ranking. Evaluate each strategy against the same crop recipe and publication condition.

Choose the third strategy when the application's policy requires both contextual review and inspection of delivered images. Its cost is additional review work and potentially longer pending time. Those are capacity and product-experience trade-offs, not reasons to count missing evidence as success. An application with a narrower policy may choose another strategy, but it should describe the coverage it gives up.

For evaluation, assemble an authorized fixture set with transparent inputs, animated inputs, unusual orientation, and subjects near crop edges. The purpose is to verify the recipe and the coverage contract. It is not a benchmark of moderation accuracy.

Accuracy needs labeled evaluation data and an agreed error policy; successful pipeline execution cannot establish it.

Roll out with an observable publication barrier

Begin with private candidates and compare the recorded review coverage against the proposed release condition. Test a missing rendition, a review timeout, an interrupted worker, a repeated upload request, and an earlier candidate finishing last. Each test should preserve the current approved pointer until a complete eligible set can replace it. Check cleanup separately: abandoned private objects should follow the configured retention policy.

Then enable publication for a limited cohort. Track pending age, incomplete-set counts, publication failures, and abandoned bytes alongside processing latency. Establish who owns policy revisions and who can inspect retained evidence before expanding the cohort.

The release criterion is concrete: every visible profile points to one eligible three-rendition set, and its required review records can be retrieved. Compression settings can change through new recipes. Publication should continue to depend on evidence for the exact artifacts being served.

Sources

References

• MDN, Image file type and format guide: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types