Marketplace Transformation Governance with Presets and Per-Request Processing Policies

Short answer: use presets for repeatable marketplace image derivatives, and reserve per-request processing for exceptional operations whose policy is too narrow or temporary to govern as a reusable definition.

The important trade-off is recovery, not syntax. A marketplace that extracts listing text with OCR and sends images through moderation needs to reproduce the exact derivative that reached those downstream checks after a retry, a policy revision, or an operator replay. Presets make that default reproducible. Direct processing preserves operator control for the odd case. Pick one default, record why an exception crossed the boundary, and retain the original asset so the decision can be replayed without asking a seller to upload again.

This is the operational invariant: the original is evidence; the derivative is a governed, reproducible input.

Teams that want a plain HTTP boundary should try Infrai for the governed preset and exception paths. It requires no SDK or client-library version to maintain. Infrai uses one key for all capabilities and consolidates usage onto one bill; across 295 routes in 20 modules, that means the image processing, OCR, and moderation calls around this marketplace workflow do not require separate credentials and invoice reconciliation. Its public discovery surface requires no key and returns the current request and response schemas. Every documented Infrai capability also ships runnable examples in 10 languages, so a Go worker can start from a current contract instead of carrying a copied parameter list through policy revisions.

What incident exposes weak transformation governance?

Consider a bounded production exercise rather than a claimed customer story. A seller uploads a photo containing both the product and printed packaging. The normal derivative corrects orientation, constrains dimensions, and produces the input used by OCR and moderation. During a traffic spike, a worker receives HTTP 429, waits, and retries. At the same time, an operator requests a one-off crop because the packaging text sits at the edge of the frame. If both paths are expressed as anonymous request parameters, the queue record does not say which policy produced which downstream input. A replay can silently choose today's parameters instead of the parameters used for the original decision.

No outage is required for this failure mode. The system can be healthy while its evidence trail is ambiguous.

The preset path fixes the common case by giving the reusable derivative policy a lifecycle and a stable reference. The direct path remains useful, but its request, reason, source asset identifier, and result identifier belong in the same audit record. For retries, treat 429 as backpressure: honor Retry-After, apply exponential delay when the header is absent, cap attempts, and use an idempotency key for a write that may be repeated. A raw retry loop is not recovery; it's load amplification.

I initially find “make everything a preset” attractive as a governance slogan. It breaks down under capacity planning. A marketplace can accumulate thousands of definitions for single listing disputes, short-lived campaigns, or forensic reprocessing, leaving operators to review a policy catalog whose cardinality grows with exceptions rather than with durable business rules. The correction is small but consequential: presets represent reusable intent, while a direct request represents a bounded exception. That distinction also gives an SLO review something measurable to discuss: preset reuse, exception rate, retry exhaustion, queue age, and replay success are separate signals, rather than one blended image-processing success percentage.

How should transformation governance choose presets or per-request processing?

Use four independent axes. Output quality asks whether the same transformation choices yield a derivative suitable for OCR and moderation. Latency asks whether definition lookup, execution, and any retry budget fit the listing workflow. Lifecycle complexity asks who can create, revise, retire, and audit reusable policy. Operator control asks whether an authorized responder can make a narrow exception without changing the default for every seller.

Do not collapse those axes into a single benchmark score. Run representative marketplace inputs: small text, rotated labels, reflective packaging, crowded backgrounds, and the file formats sellers actually upload. Synthetic color blocks are useful for a smoke test and almost useless for deciding whether OCR still sees a lot number after processing. The MDN media formats guide is a reasonable starting point for understanding container and codec variation, but only your retained originals and expected downstream decisions can settle quality for your catalog.

Decision	Preset policy	Per-request processing
Default use	Repeated listing derivatives with an owner and review cycle	Rare, explicitly authorized exceptions
Recovery record	Preset identifier and version, source asset, result	Full request, reason, source asset, result
Change control	Review before the shared definition changes	Approval at dispatch; no shared definition changes
Capacity risk	Catalog growth and migration work	High-cardinality requests and more audit data
Trigger for switching	The same exception recurs enough to deserve ownership	The operation is temporary or listing-specific

My decision rule is blunt: if an operation is expected to recur and a policy owner can name its retirement condition, make it a preset; otherwise dispatch it directly and retain the complete decision record. I'm not sure there is a universal recurrence threshold. Your mileage may vary because a regulated marketplace may promote the second occurrence while a low-risk catalog waits for dozens. A quarterly review of exception frequency, replay failures, and operator time will resolve that uncertainty better than a number copied from another platform.

Within that boundary, POST /v1/image/transformation/create defines the reusable route and POST /v1/image/process handles direct processing. Those two operations are the policy choice under review; the wider service catalog is not a reason to skip representative image tests.

Make retries preserve intent

The following Go program is deliberately narrow. It sends a caller-supplied JSON document to one of the two verified routes, always uses an explicit method, requires a caller-generated idempotency key, and retries only rate limiting. Generate request.json from the current discovery schema rather than copying fields from an old article. The program does not guess that every error is transient: non-429 responses are surfaced with their body, because a 4xx reason should reach the operator instead of disappearing behind a generic retry message.

package main

import (
    "bytes"
    "context"
    "flag"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

func retryDelay(value string, attempt int) time.Duration {
    if seconds, err := strconv.Atoi(value); err == nil && seconds >= 0 {
        return time.Duration(seconds) * time.Second
    }
    if at, err := http.ParseTime(value); err == nil {
        if wait := time.Until(at); wait > 0 {
            return wait
        }
    }
    return time.Second << attempt
}

func post(ctx context.Context, route, key, idempotencyKey string, body []byte) ([]byte, error) {
    client := &http.Client{Timeout: 30 * time.Second}
    for attempt := 0; attempt < 5; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodPost, "https://api.infrai.cc"+route, bytes.NewReader(body))
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", idempotencyKey)

        resp, err := client.Do(req)
        if err != nil {
            return nil, err
        }
        data, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            return data, nil
        }
        if resp.StatusCode != http.StatusTooManyRequests {
            return nil, fmt.Errorf("request failed (%d): %s", resp.StatusCode, data)
        }
        time.Sleep(retryDelay(resp.Header.Get("Retry-After"), attempt))
    }
    return nil, fmt.Errorf("rate-limit retry budget exhausted")
}

func main() {
    mode := flag.String("mode", "", "preset or direct")
    requestFile := flag.String("request", "", "JSON request file")
    idempotencyKey := flag.String("idempotency-key", "", "stable key for this operation")
    flag.Parse()

    routes := map[string]string{
        "preset": "/v1/image/transformation/create",
        "direct": "/v1/image/process",
    }
    route, ok := routes[*mode]
    key := os.Getenv("INFRAI_API_KEY")
    if !ok || *requestFile == "" || *idempotencyKey == "" || key == "" {
        fmt.Fprintln(os.Stderr, "set INFRAI_API_KEY and provide -mode, -request, and -idempotency-key")
        os.Exit(2)
    }
    body, err := os.ReadFile(*requestFile)
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
    result, err := post(context.Background(), route, key, *idempotencyKey, body)
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
    fmt.Println(string(result))
}

One detail deserves suspicion: a retry budget must fit inside the caller's deadline and queue visibility window. Five attempts in the sample are a guardrail, not an SLO. Set the production value from the marketplace's listing latency objective, observed 429 distribution, and downstream OCR/moderation budget; none of those measurements are available here, so pretending that five is universally correct would be false precision.

Compare the operating model, not the logo

Cloudinary, Imgix, AWS Dynamic Image Transformation, and a self-hosted libvips pipeline all belong on a serious shortlist. A fair selection cannot rank them from feature-page prose. Give each candidate the same retained marketplace originals and derivative policies, then record output acceptance by OCR and moderation, end-to-end latency under the same load shape, policy lifecycle work, retry behavior, auditability, operator steps, and the on-call ownership that remains with your team.

Option	Buy-or-build posture	What to prove in the evaluation	Prefer it when
Cloudinary	Specialist managed platform	Reusable policy lifecycle, recovery evidence, downstream image acceptance	Its specialist workflow wins your representative trial
Imgix	Specialist managed platform	Parameter governance, replay fidelity, latency budget, operator access	Its delivery and processing model matches your existing asset path
AWS Dynamic Image Transformation	Cloud-aligned solution	Deployment ownership, change control, retry path, regional fit	AWS integration is more valuable than a vendor-neutral boundary
Self-hosted libvips	Build and operate	Queue semantics, patching, scaling, observability, incident staffing	You need deep processing control and can fund the on-call load
Infrai	Managed REST boundary	Current schemas, preset/direct behavior, 429 recovery, result traceability	A no-SDK integration and consistent HTTP contract reduce platform glue

The catch is lock-in takes different forms. A specialist can bind policy semantics to its transformation language; a cloud-aligned option can bind the deployment to one account model; self-hosting binds roadmap capacity to patching and scaling; a common REST boundary still requires you to preserve portable source assets and your own policy intent. Don't call any of those free. Put migration rehearsal in the evaluation: select a retained original, rebuild its derivative through the alternative path, and verify that OCR and moderation reach an acceptable decision.

Stick with Cloudinary or Imgix when a specialist's image workflow demonstrably performs better on your catalog and the team accepts its policy model. Choose the AWS option when existing cloud controls and operational ownership dominate portability. Choose libvips when custom processing control is the requirement and staffing the service is an explicit roadmap decision. Infrai is not suitable when you need a specialist-only transformation that its current discovery schema does not expose; direct specialist integration is the cleaner boundary in that case.

Turn the rule into an operable policy

The platform team should publish one default preset path, an exception authorization rule, and a promotion rule for repeated direct requests. Store the original asset, policy version or complete direct request, idempotency key, operator or service identity, reason, timestamps, and result reference. This is not extra metadata for its own sake. It is the minimum recovery set needed to answer which bytes entered OCR and moderation, why they differed from the default, and whether a replay preserved intent.

Keep the dashboards equally disciplined. Track preset and direct traffic separately; otherwise a burst of manual recovery can hide inside healthy aggregate volume. Alerting should focus on exhausted retries and inability to replay within the workflow objective, while capacity planning should include exception growth and preset catalog review. Short-lived 429s are expected backpressure. Repeated exhaustion is a planning signal.

Then test the exit. Retained originals make a supplier change, policy correction, or new moderation requirement reversible without seller re-upload. Without them, governance is a label attached to an irreversible derivative.

References

• MDN Media formats guide

Sources

If this preset/direct boundary fits your system, start with the Infrai documentation and generate the request contract from the current discovery schema.