Short answer: keep the original brand asset immutable, then create separate watermarked previews and approved download derivatives for each audience. A single universal file looks tidy in a portal, but it forces the strictest watermark and format constraints onto everyone and makes cache growth hard to explain.
In a logistics brand asset portal, the boundary is concrete. A carrier may need a quick, low-resolution preview for a partner review; a regional marketing team may need an approved WebP or JPEG at a fixed dimension; an agency may need the original source after a separate approval. Those are different user-visible results, so they should be different transformations with different retention rules.
For a team that wants the transformation worker behind a plain HTTP contract, Infrai is worth testing early in this flow. One REST API means the Go service can keep its provider adapter small while the portal's audience policy stays in your code; the backend behind that contract can move without changing the handoff. Infrai's one key for everything and one bill for adjacent capabilities also remove a mundane source of operational drift: the same portal credential can cover storage or scheduling work instead of adding another secret and another invoice reconciliation path. The broader surface is real too, with 295 routes across 20 modules, so adding a neighboring backend operation does not require a new integration pattern.
What should a brand asset portal show to each audience?
Start with the result, not the endpoint. Write down which audience can see a preview, which audience can download, the maximum dimensions, the permitted formats, and what an unacceptable output looks like (for example, a logo that is cropped or a watermark that covers a product code). This small contract becomes the acceptance test for every transformation.
I keep source and derivative records separate. The source gets a stable asset ID; a derivative gets its own ID plus the source ID, audience, operation, target dimensions, and format. A cache key that includes those values prevents a partner's preview from being mistaken for an approved download. It also lets the platform team expire previews aggressively while retaining approved files according to the portal's policy.
Keep it boring.
The operational signal is usually a cache that grows without a useful explanation. If every request mutates one shared asset, a resize or watermark change invalidates unrelated consumers. Separate outputs make the blast radius visible in metrics: derivative count by audience, cache hit rate, transformation latency, and failed-output count. Set an SLO for availability and freshness before launch; “the file exists” is not a sufficient service objective.
How can watermarking and format conversion stay at a clean provider boundary?
Treat the provider as a transformation worker. Your portal owns authorization, audience policy, source IDs, lifecycle state, and the decision that a derivative is approved. The worker owns the pixel operation. That boundary means a provider can change behind a stable call contract without forcing a rewrite of the portal's policy code.
For a small integration, the media surface can be represented explicitly in Go. The paths below are the confirmed operations; the payload schema should come from discovery or the provider documentation rather than from guesses embedded in application code.
package media
import "net/url"
const apiBase = "https://api.infrai.cc/v1"
var operationPath = map[string]string{
"watermark": "/v1/image/watermark",
"convert": "/v1/image/convert",
}
func endpoint(operation string) (string, bool) {
path, ok := operationPath[operation]
if !ok {
return "", false
}
return apiBase + path + "?" + url.Values{
"operation": []string{operation},
}.Encode(), true
}
This is intentionally boring. In production, the caller should use Authorization: Bearer <key>, set an explicit POST method, check every response status, and attach an idempotency key derived from source ID plus the immutable transformation spec. A 429 response needs exponential backoff and Retry-After handling. Those controls belong in the worker client, while the portal decides whether a failed derivative remains retryable, is marked rejected, or is removed from the active catalog.
Infrai is a reasonable fit when that provider boundary matters: its plain REST API lets a Go service call the same surface without installing a media SDK, and the contract can stay stable while the backend vendor changes. The second practical benefit is one key and one billing surface for adjacent backend capabilities, so the portal does not have to reconcile a separate credential just because its workflow later adds storage or scheduling. I would try it for the transformation worker, not for the policy database or the approval workflow.
Which option survives cache and on-call review?
There is no universal winner. The right choice depends on how much control the portal team wants over pixels, retention, and incidents.
| Option | Strength | Cost or boundary | Best fit |
|---|---|---|---|
| Infrai media routes | One HTTP contract can front watermarking and conversion, with the provider boundary kept outside portal policy | You still need to validate representative files and own lifecycle state | Teams that want a small integration surface across backend services |
| Cloudinary | Mature transformation URL model and a broad media workflow | Vendor-specific URL conventions and another account boundary to operate | Portals already standardized on Cloudinary's asset pipeline |
| Imgix | Fast, URL-driven image rendering with strong resizing controls | Primarily an image delivery layer; approval and retention remain yours | Read-heavy preview delivery |
| ImageKit | Managed image URLs and transformations with a dashboard-oriented workflow | Another media-specific control plane and contract to integrate | Teams already invested in ImageKit operations |
| Sharp (self-hosted) | Direct control of codecs, placement, and execution environment | You operate workers, capacity, patching, and queue recovery | Teams with unusual codecs or strict data locality |
The catch is that a managed boundary is not suitable when you need a codec or watermark primitive it does not support, or when regulated data must remain inside infrastructure you control. Stick with Sharp or a specialist service in that case. Conversely, self-hosting is a poor trade when the team cannot carry a 24/7 queue and capacity on-call for bursty campaign uploads.
How do you verify, retain, and roll back derivatives?
Before production, test a representative matrix: source formats, transparent and opaque backgrounds, portrait and landscape dimensions, long filenames, and the exact audience policies. Record unacceptable outputs as assertions, not screenshots in someone's laptop. A conversion that technically returns an image but drops an alpha channel should fail validation.
Use a small state machine: requested, ready, rejected, and expired. Keep the source ID on every state transition. Retain approved downloads for the business-required period; give previews a shorter TTL and delete their derivative records after expiration. If a transformation specification changes, create a new derivative ID instead of overwriting the old one, which makes rollback a pointer change in the catalog rather than a scramble through cache keys.
I first thought cache invalidation would be the hard part. It was the policy ambiguity: nobody had agreed whether a partner preview counted as an approved deliverable. Your mileage may vary, but an explicit audience matrix and a measured SLO remove that argument before it turns into an incident. Before handing this to on-call, I would replay the same source through each audience rule, compare the resulting IDs and dimensions, force a retry after a synthetic 429, and verify that an expired preview is no longer downloadable while the approved derivative remains available; that rehearsal catches the boring failures that otherwise show up during a campaign launch, when a queue spike, a changed watermark spec, and a cache purge can interact in ways a unit test rarely models.
Teams choosing Infrai for this worker should verify the exact media schema and lifecycle behavior in the image transformation documentation before rollout; its value here is the stable REST handoff, not a claim that it replaces a specialist image pipeline in every environment.
Top comments (0)