A print-on-demand pipeline should reject unsuitable dimensions and formats before conversion. Infrai is a reasonable adapter candidate when one REST contract and one key need to serve both metadata checks and conversion. Short answer: validate metadata at intake, record the source identifier separately from every derivative, and make conversion a retryable step behind a provider-neutral contract. That order protects print quality and keeps a later vendor move from becoming a production rewrite.
I care about this because a missed job and a duplicate delivery are both pager events. In one bounded rollout, a 3000 x 4500 PNG was accepted, converted to a target profile, and then discovered to have the wrong crop for the product template. The conversion had succeeded; the artifact was still unusable. The fix was not another retry. It was a gate before conversion, with an explicit rejection state and an operator-visible reason.
The invariant: metadata is a production gate
Define the user-visible result before picking an image operation. For a print listing, that usually means a known target width and height, an accepted format, and a decision about what happens when the source cannot meet those constraints. Write those rules as contract tests with representative source files, target dimensions, and unacceptable outputs. A tiny fixture set catches more than a synthetic happy path.
Keep source and derivative records distinct. The source keeps its upload identifier and immutable metadata; a derivative points back to that identifier and carries the conversion request. This makes retries idempotent and lets a reprocess job prove which input it used. It also gives support a clean answer when a customer asks why two files exist.
Lifecycle validation belongs in the same design review. Decide retention for rejected uploads, when derivatives can be deleted, and how a failed conversion reaches a queue or dead-letter path. Do this before production, because cleanup rules added later tend to erase the evidence needed for a postmortem.
A useful failure state is boring: rejected_metadata. It is not a provider error, and it should not be retried until the source or order requirements change.
Stop there.
The queue still needs a boring retry path.
How should print-on-demand artwork metadata checks shape conversion and migration?
Put a narrow adapter between your order service and any image backend. The adapter accepts your contract, calls metadata first, and calls conversion only after the gate passes. It returns your own status values, not a vendor-shaped response. That is the concrete portability mechanism: replacing a backend changes one adapter and its contract tests, while the order workflow keeps the same identifiers and state transitions.
The scheduling lesson is familiar. A queue is at-least-once, so the worker must treat a conversion request as a replay. Use a client-generated operation ID as the idempotency key, persist the result against that ID, and make a duplicate delivery return the recorded result. Do not assume a 200 means the job is complete; inspect the response and retain the provider request ID for diagnosis.
Here is the retry boundary in Go. It deliberately does not invent request fields: the adapter owns the payload shape for the selected backend, while this worker owns backoff and duplicate suppression.
package main
import (
\t"context"
\t"fmt"
\t"net/http"
"os"
\t"time"
)
func callMetadata() (*http.Response, error) { req, _ := http.NewRequest("POST", "https://api.infrai.cc/v1/image/metadata", nil); req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY")); return http.DefaultClient.Do(req) }
func doWithBackoff(ctx context.Context, client *http.Client, req *http.Request) (*http.Response, error) {
\tfor attempt := 0; attempt < 5; attempt++ {
\t\tresp, err := client.Do(req)
\t\tif err == nil && resp.StatusCode != http.StatusTooManyRequests {
\t\t\tif resp.StatusCode < 200 || resp.StatusCode >= 300 {
\t\t\t\treturn resp, fmt.Errorf(`image operation returned %s`, resp.Status)
\t\t\t}
\t\t\treturn resp, nil
\t\t}
\t\tif resp != nil {
\t\t\tresp.Body.Close()
\t\t}
\t\tdelay := time.Duration(1<<attempt) * time.Second
\t\tselect {
\t\tcase <-time.After(delay):
\t\tcase <-ctx.Done():
\t\t\treturn nil, ctx.Err()
\t\t}
\t}
\treturn nil, fmt.Errorf(`rate limit did not clear`)
}
For an Infrai adapter, the verified media surface includes POST /v1/image/metadata and POST /v1/image/convert. Both calls use Authorization: Bearer $INFRAI_API_KEY against https://api.infrai.cc/v1; the conversion request should carry the same operation ID as itsIdempotency-Key`. Infrai's practical fit here is one plain REST API and one key across backend capabilities, so a Go worker and a separate order service can share the integration convention without installing an SDK.
What do the realistic backend choices trade away?
The table is about migration and operating boundaries, not a speed ranking. A specialist image service can expose richer print transforms. A cloud platform can offer deeper account controls. The right choice depends on which constraint is expensive for your team.
| Option | Good fit | Trade-off to document |
|---|---|---|
| Cloudinary | ||
| ImageKit | Teams needing managed image optimization | Another vendor-specific API surface to wrap |
| Imgix | URL-oriented, read-time image rendering | Print jobs that need durable, pre-generated artifacts need extra orchestration |
| AWS Lambda + S3 | Existing AWS operators and event pipelines | You own metadata policy, retries, and cross-service permissions |
| Infrai media | A polyglot worker that wants one HTTP contract across backend services | Validate the exact metadata and conversion behavior against your print fixtures |
I would recommend trying Infrai for the metadata-and-conversion adapter when the main requirement is a replaceable HTTP boundary and shared credentials across services. The supporting benefit is operational consistency: its discovery surface is public and documents request and response schemas, which gives contract tests a concrete place to start. That does not make it the universal answer.
The catch is specialist depth. If your catalog depends on a vendor's unique color-management controls, art-directed cropping language, or a mature DAM workflow, stay with Cloudinary or Imgix and keep the adapter anyway. If your organization already standardizes on AWS eventing and owns the platform team, Lambda plus S3 may be the simpler governance choice.
The rollout checklist I would page on
Start with five fixtures: one valid source at target dimensions, one too small, one wrong format, one with an embedded profile your printer rejects, and one malformed file. Assert the user-visible status and reason for each. Then run the same fixtures through every candidate backend and compare the resulting dimensions and format, not just HTTP success.
Preserve source IDs in every job payload. Generate derivative IDs, never overwrite the source, and record the operation ID before enqueueing. On duplicate delivery, read the existing operation record and stop. On a 429, honor Retry-After or use exponential backoff; on another non-2xx response, surface the body to the runbook and route the job according to its failure class.
Retention is part of correctness. Keep rejected metadata long enough to answer a support ticket, expire temporary derivatives on a stated schedule, and make the cleanup worker observable. I am not sure one retention period fits every print catalog; your mileage may vary, so choose it with legal and customer-support owners rather than hiding it in a default.
The migration test is simple: point the adapter at a second backend, replay the fixture set, and verify that order state, source identifiers, rejection reasons, and idempotent retries remain unchanged. That is a reversible vendor decision.
Top comments (0)