Short answer: process marketplace product images at upload for the stable catalog renditions, retain the original, and reserve on-demand work for new or uncommon views.
The deciding constraint is search. A customer-support team cannot reliably auto-tag a media library when two requests for the same asset can encounter different transformation states. Upload-time processing gives the tagger and the catalog a named, inspectable set of inputs. On-demand processing still has a useful role, but it should be the exception rather than the source of the canonical photo.
The mental model is short. Before: upload an original, let every reader request a size and format, then hope caches hide the variation. After: accept an original, create a small catalog contract once, tag those stable outputs, and derive unusual renditions only when a real request needs them.
That split is the recommendation. The rest is about making it operable.
How should marketplace product images be processed for consistent catalog photos?
Treat each upload as a state transition, not as a file copy. The image begins as accepted, moves through validation and normalization, becomes ready only when every required rendition exists, and becomes searchable only after the tagging result points at that same generation. A listing should not expose half of a generation. This is the key consistency rule.
For a support media library, define a compact contract around use, not arbitrary dimensions. One rendition might feed the catalog grid, another the product detail view, and a third the support-search index. The names are stable even if the exact encoding policy changes later. Keep the uploaded original as the rebuild source; otherwise, a future format or crop policy forces the team to transform an already transformed image.
The order matters:
- Validate the upload and assign an immutable asset ID.
- Store the original and record its checksum.
- Build every required rendition under a new generation ID.
- Run auto-tagging against the designated search rendition.
- Publish the generation atomically, then make it visible to catalog and support search.
No partial reveal.
Media format support varies by browser, container, codec, and platform, so the accepted input set and emitted output set should be explicit policy rather than whatever a library happens to decode. The MDN media format guide is a useful starting point for that compatibility conversation. It does not choose the policy for a particular marketplace; actual client traffic and visual requirements must do that.
Make the pipeline observable before making it clever
The most useful dashboard is a diagram in words: upload received -> original stored -> renditions complete -> tags attached -> generation published. Put a counter and a duration around every arrow. Then an operator can distinguish a slow transformer from a slow tagger without reading application logs one request at a time.
Track queue age separately from processing duration. A job can execute quickly after waiting too long, and a single end-to-end timer hides that distinction. Also count outcomes by stage and stable reason code. INPUT_UNSUPPORTED is actionable in a different way from TAG_POLICY_REJECTED; putting both into a generic failed bucket makes alerts loud and diagnosis slow. These are example names for an internal contract, not claims about a third-party API.
Cardinality deserves restraint. Asset IDs belong in structured logs and traces, not metric labels. Metrics answer whether the system is drifting; a log keyed by generation ID explains which item drifted. For alerts, watch the user-facing boundary: the age of the oldest unpublished accepted upload and the ratio of generations that reach ready. A CPU graph may explain an incident, but it does not define whether catalog photos are available.
I wouldn't hard-code a universal latency objective here. A marketplace with moderated listings has a different acceptable delay from one promising immediate publication, and I'm not sure a useful threshold can be chosen without both the publication promise and a baseline from real uploads. Start by measuring the stage distribution, set the objective from the product promise, and alert on sustained violations rather than one large photograph.
One subtle failure mode is version skew. If a normalization policy changes while work is queued, recording only assetId leaves the output's recipe ambiguous. Record policyVersion, generationId, input checksum, and tagging model revision with the result. The catalog pointer then selects one complete generation, while a rebuild writes a different generation beside it. Rollback becomes a pointer change instead of an emergency image conversion.
A copyable TypeScript boundary
Keep orchestration independent of the image implementation. The following example is deliberately an interface boundary: adapters can run locally, in a worker fleet, or behind a plain HTTP service, while the state machine stays testable. All identifiers and policies are illustrative application data.
type Stage =
| "accepted"
| "original-stored"
| "renditions-complete"
| "tagged"
| "ready";
type RenditionName = "catalog-grid" | "product-detail" | "support-search";
interface Upload {
assetId: string;
bytes: Uint8Array;
mediaType: string;
checksum: string;
}
interface Generation {
assetId: string;
generationId: string;
policyVersion: string;
}
interface PipelinePorts {
storeOriginal(upload: Upload): Promise<void>;
render(
generation: Generation,
name: RenditionName,
source: Uint8Array,
): Promise<string>;
tag(searchRenditionUri: string): Promise<string[]>;
publish(generation: Generation, tags: string[]): Promise<void>;
recordStage(generation: Generation, stage: Stage): Promise<void>;
recordDuration(stage: Stage, milliseconds: number): void;
}
const requiredRenditions: RenditionName[] = [
"catalog-grid",
"product-detail",
"support-search",
];
async function timed<T>(
stage: Stage,
ports: PipelinePorts,
work: () => Promise<T>,
): Promise<T> {
const startedAt = Date.now();
try {
return await work();
} finally {
ports.recordDuration(stage, Date.now() - startedAt);
}
}
async function processUpload(
upload: Upload,
generation: Generation,
ports: PipelinePorts,
): Promise<void> {
await ports.recordStage(generation, "accepted");
await timed("original-stored", ports, async () => {
await ports.storeOriginal(upload);
});
await ports.recordStage(generation, "original-stored");
const outputs = new Map<RenditionName, string>();
await timed("renditions-complete", ports, async () => {
const rendered = await Promise.all(
requiredRenditions.map(async (name) => [
name,
await ports.render(generation, name, upload.bytes),
] as const),
);
rendered.forEach(([name, uri]) => outputs.set(name, uri));
});
await ports.recordStage(generation, "renditions-complete");
const tags = await timed("tagged", ports, () =>
ports.tag(outputs.get("support-search")!),
);
await ports.recordStage(generation, "tagged");
await ports.publish(generation, tags);
await ports.recordStage(generation, "ready");
}
The non-null assertion is safe only because support-search is a required rendition and Promise.all must finish before tagging begins. A production implementation should encode that invariant more strongly, perhaps by returning a typed object from the rendition stage instead of a map. The point is the boundary: publish happens last and receives the generation plus its tags together.
Test it with faults at each port. A test can reject render, verify that publish was never called, retry the same generation, and confirm that the adapter treats already stored outputs idempotently. Another test can complete generation B while generation A is still running and verify that only an explicit publication rule moves the catalog pointer. Those tests exercise the consistency promise; pixel snapshots alone do not.
What does on-demand processing still do well?
On-demand transformation fits renditions with low reuse or requirements that cannot be known at upload. A rarely opened zoom level is a reasonable candidate. So is an internal diagnostic view that should not delay publication. In both cases, key the cache by original checksum, transformation policy version, and requested rendition. A URL alone is not a sufficient recipe if its meaning can change after a deployment.
The catch is cold-request latency and a larger runtime failure surface. The reader request now depends on transformation capacity, so cache misses must be visible as their own event. Measure hit ratio, transformation duration, and request outcome separately. Do not silently substitute a differently cropped image when the requested rendition is unavailable; return a documented placeholder owned by the application policy, and keep that response distinguishable in telemetry.
Upload-time work has the opposite trade-off: publication waits for required processing, storage grows with precomputed variants, and unused renditions consume work. It is not suitable when transformation parameters are highly personalized or effectively unbounded. Stick with on-demand processing for those views, while retaining one stable rendition for tagging and search. A hybrid is less tidy than choosing one mode everywhere, but it aligns the work with reuse.
There is a second objection: why block the catalog on auto-tagging at all? You don't always have to. If tags improve support search but are not part of the public listing contract, publish the visual generation after required renditions finish and track tagging as a separate indexed state. The search UI must then represent “not indexed yet” honestly, and an alert must cover tag backlog age. If search correctness is required at first publication, keep tagging inside the generation boundary. That choice belongs to product semantics, not the image library.
Choose the boundary with one decision rule
Precompute a rendition when it has bounded variants, high reuse, or participates in publication and search consistency. Generate it on demand when variants are sparse, personalized, or unknown until request time. Keep the original in either design, version the recipe, and make a generation visible only at a boundary the application can explain.
For this marketplace support library, that means upload-time normalization for the grid, detail, and search inputs, followed by auto-tagging against the stable search image. It means on-demand work for uncommon views. The operational proof is equally concrete: every accepted upload can be followed through named stages, every published catalog pointer resolves to one complete generation, and every search tag identifies the image recipe that produced it.
That's the whole decision. Crisp inputs. Observable stages. One publish point.
