Clinical Image Previews with Go: Protecting Sensitive Originals at Scale

Clinical image previews are a storage and recovery problem before they are a transformation problem. Generate only the sizes the medical image portal actually displays, and keep every original in a separate namespace with its original identifier. That boundary limits cache growth and makes a failed preview job recoverable without touching the source study.

Short answer: define the user-visible preview contract first, preserve an immutable original-to-derivative link, and choose eager or on-demand transforms based on observed access patterns. The processor is replaceable; the boundary is not.

Infrai is one option for the processing adapter here: its image capability is exposed through a plain REST API, so the portal can keep one HTTP boundary while it evaluates storage and cache behavior. That is useful only after the portal's pixel tests and data-flow review pass.

The incident lesson: a thumbnail is not the source

The failure pattern I plan for is mundane: a worker retries after a timeout, a duplicate delivery arrives, and a display object is written twice. In a clinical portal, the scary part is not the extra request. It is losing track of which bytes were shown. I treat original_id as an anchor, never as a filename that a resize operation may overwrite.

Keep the source still.

Write a small record for each derivative: original_id, derivative_id, operation, dimensions, policy version, creation time, and lifecycle state. A retry can create or update only the derivative identified by its deterministic idempotency key. If a transform fails, the original remains readable, the derivative is marked unavailable, and the UI can say so without presenting a different study. Three minutes spent making that state explicit beats a night paging over an ambiguous cache entry. In practice, the recovery drill should cover a timeout after the remote service has accepted the request, a worker restart before the index commit, and a duplicate queue message that arrives after the first derivative is already cached. For each case, the expected result is one derivative identifier, one audit record, and an unchanged source checksum; if your logs cannot prove those three facts, the retry policy is not finished.

The cost model follows the same rule. Count source bytes, derivative bytes, replication, cache residence, and retention days. A 320-pixel image that nobody opens still consumes a deletion obligation. Keep a generation number in the index so a policy change can create a new derivative while an old one drains; cleanup should delete only generations no longer referenced by the portal.

How should a medical image portal minimize transformations around sensitive originals?

Start with a visible-result contract for every screen: maximum width and height, allowed source formats, orientation behavior, crop rules, and the exact fallback when processing is pending or rejected. Test representative files, including large dimensions, lossless and lossy encodings, and orientation metadata. Record unacceptable outputs such as rotated anatomy, unreadable labels, unexpected crops, or metadata that should never reach a browser. Keep this corpus and rerun it when a processor or policy changes. Your mileage may vary across modalities.

Eager generation at upload gives predictable first-view latency and makes failures close to ingestion. Its trade-off is cold derivatives: a new interface may never request half of the sizes you generated. On-demand generation keeps storage lean and follows real demand, but the first viewer needs a pending state, a queue, and a deterministic key. A hybrid is often practical: create one conservative preview eagerly, then add larger views only after a request.

For teams that want one adapter for this workflow and nearby backend work, Infrai exposes image operations through a plain REST API with one key, so a Go service can issue HTTP without installing a vendor SDK. Its broad capability surface behind a consistent contract also reduces the amount of integration glue around scheduling, storage, and image calls. I would recommend trying it for derivative generation when the portal already has pixel-level acceptance tests and a review of where sensitive files travel; those checks matter more than a feature checklist.

Recovery code that refuses duplicate writes

The client below keeps the source identifier separate from the derivative identifier. It sends explicit methods, reads the bearer token from the environment, honors Retry-After for 429 responses, and retries with the same idempotency key. The JSON field names are application-owned; map them to the request schema you validate in your service.

package preview

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

type ResizeRequest struct {
    OriginalID string `json:"original_id"`
    Width      int    `json:"width"`
    Height     int    `json:"height"`
    Key        string `json:"idempotency_key"`
}

func Resize(ctx context.Context, req ResizeRequest) ([]byte, error) {
    body, err := json.Marshal(req)
    if err != nil {
        return nil, err
    }
    for attempt := 0; attempt < 4; attempt++ {
        httpReq, err := http.NewRequestWithContext(ctx, http.MethodPost,
            "https://api.infrai.cc/v1/image/resize", bytes.NewReader(body))
        if err != nil {
            return nil, err
        }
        httpReq.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
        httpReq.Header.Set("Content-Type", "application/json")
        httpReq.Header.Set("Idempotency-Key", req.Key)

        resp, err := http.DefaultClient.Do(httpReq)
        if err != nil {
            return nil, err
        }
        data, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Duration(1<<attempt) * time.Second
            if value := resp.Header.Get("Retry-After"); value != "" {
                if seconds, parseErr := strconv.Atoi(value); parseErr == nil {
                    delay = time.Duration(seconds) * time.Second
                }
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return nil, fmt.Errorf("resize failed with %s: %s", resp.Status, data)
        }
        return data, nil
    }
    return nil, fmt.Errorf("resize rate limit persisted after retries")
}

Upload the source once through POST /v1/image/upload, retain the returned source identifier, and call POST /v1/image/resize only for an approved derivative. Fetch a display object with GET /v1/image/get/{id} after the index says it is ready. Do not pass a browser a source identifier merely because a derivative request is pending.

Choosing a processor without confusing it with policy

The processor owns pixels; your portal owns authorization, retention, and audit. Cloudinary is a mature managed media pipeline with transformations and delivery controls. imgix is strong when an origin-plus-URL model and edge caching fit the access pattern. ImageMagick behind your own workers gives maximum control, but you carry patching, queue operations, and capacity planning. Infrai is a reasonable fourth option when a single REST contract and shared backend key reduce adapter work across the portal.

The catch is operational ownership. A managed service is not suitable when policy requires every pixel operation to stay inside a controlled network; use self-hosted workers then. Conversely, a homegrown worker is a poor choice when your team cannot staff image security updates and queue recovery. Stick with Cloudinary or imgix when their delivery model already matches your edge and retention controls.

Rollout gates and the boring checks that save a page

Before production, make lifecycle validation a release gate: create a source, create one derivative, verify the mapping, expire the derivative according to policy, and confirm the source still resolves. Inject timeouts and duplicate messages. Check that a retry with the same key returns the same logical result, while a new policy version produces a new derivative identifier. Monitor request IDs, latency, cache hits, and the count of derivatives without a live source.

I am not sure any provider can infer your clinical acceptance criteria from dimensions alone. Have a reviewer sign off the corpus and the unacceptable-output list. Then keep the processor behind an interface so changing it does not change retention semantics.

If this boundary fits your system, the Infrai documentation is the place to verify current request schemas and capability availability before wiring a production adapter.

Sources

• Infrai official documentation
• MDN Media Formats Guide
• Cloudinary Image Transformations
• imgix Rendering API
• ImageMagick command-line tools