Run the photo booth transformations in one fixed order at upload time, and persist the result of every stage before starting the next one. Short answer: rotate to the camera's intended orientation, crop to the print frame, resize to the delivery dimensions, then apply the watermark.
That order is the product contract. A kiosk can be offline for a few seconds, a queue can deliver a message twice, and an operator can replay a job after a power cycle. If the same source can produce two different derivatives, support gets a mystery instead of a filename. The useful unit of work is therefore a chain of explicit stages, not a single opaque "process image" call.
Why order matters in a photo booth pipeline
The input is a camera asset plus metadata: orientation, crop rectangle, output width and height, and watermark placement. Store those values with a job identifier before touching the bytes. The derivative identifier for each stage should point back to its parent, so cleanup can remove an abandoned branch without guessing which file is safe.
Rotation must happen first because the crop rectangle is expressed in the display coordinate system. Cropping first can select the wrong edge when the camera writes an EXIF orientation rather than rotated pixels. Resizing before cropping also changes the coordinate math and makes a frame that looked correct in testing drift at another input size. Watermarking last keeps the mark at a predictable visual size and prevents it from being clipped by a later crop.
Small detail, big incident.
No guesswork.
I treat each stage as a state transition: pending, running, succeeded, or failed. A worker may claim a pending stage, write its idempotency key, and submit the transformation. It must validate the returned derivative before publishing the next message. Validation includes dimensions, format, byte size limits, and the expected parent identifier. A successful HTTP response alone is not proof that the artifact is suitable for printing. In one realistic replay, a kiosk uploaded the same 7.8 MB source twice after losing power; the two messages carried the same manifest hash, so the worker returned the existing derivative instead of creating another print job. The important part was not a clever queue setting. It was recording the parent id, stage version, and key before the first attempt, then making the database transition conditional on that exact tuple.
How should a photo booth rotate, crop, resize, and watermark outputs?
Use a manifest with immutable inputs and deterministic parameters. For example, the crop rectangle is recorded as (x, y, width, height) against the rotated image, while resize stores the exact target dimensions. The watermark stage stores the asset identifier and anchor, not a vague instruction such as "bottom right." If you later change a default, create a new manifest version; do not silently reinterpret old jobs.
The following Go fragment shows the important boundary: every write has an application idempotency key, an explicit method, and a retry path that respects Retry-After. It demonstrates two stages; the same runner invokes the resize and watermark stages with their versioned parameter records.
package main
import (
"bytes"
"context"
"encoding/json"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
type stageRequest struct {
AssetID string `json:"asset_id"`
Params any `json:"params"`
}
func callStage(ctx context.Context, path, key string, body stageRequest) ([]byte, error) {
payload, err := json.Marshal(body)
if err != nil { return nil, err }
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodPost,
os.Getenv("INFRAI_BASE_URL")+path, bytes.NewReader(payload))
if err != nil { return nil, err }
req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Idempotency-Key", key)
resp, err := http.DefaultClient.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 == 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("stage %s: status %d: %s", path, resp.StatusCode, string(data))
}
return data, nil
}
return nil, fmt.Errorf("stage %s: retry limit reached", path)
}
func main() {
ctx := context.Background()
asset := "asset-2026-09-11-00042"
rotated, err := callStage(ctx, "/image/rotate", "job-42-rotate-v1", stageRequest{AssetID: asset, Params: map[string]int{"degrees": 90}})
if err != nil { panic(err) }
var result struct { AssetID string `json:"asset_id"` }
if err := json.Unmarshal(rotated, &result); err != nil || result.AssetID == "" { panic("rotate returned no derivative id") }
_, err = callStage(ctx, "/image/crop", "job-42-crop-v1", stageRequest{AssetID: result.AssetID, Params: map[string]int{"x": 0, "y": 0, "width": 1200, "height": 1600}})
if err != nil { panic(err) }
}
In production, the runner records the response envelope and emits the next stage only after schema validation. A retry with the same key must resolve to the original derivative, while a new manifest version receives a new key. That distinction prevents a replay from creating a second printable asset.
Verification and rollback before the kiosk says “ready”
The kiosk should receive a status event only after the final derivative passes checks. Verify that the lineage is complete (source -> rotate -> crop -> resize -> watermark), dimensions match the print profile, and the output can be fetched by the delivery worker. Keep the source and derivatives under separate retention policies; a support ticket often needs the source even after the branded output has been downloaded.
Polling needs a stop condition. Accept only documented terminal states such as succeeded or failed, cap the number of polls, and persist the last response so an operator can resume without resetting the job. A five-minute timeout is a policy choice for your queue, not a reason to invent a new remote state.
Rollback means choosing the last known-good derivative, not re-running every stage with today's defaults. If watermark placement version 2 is rejected by a print check, mark that stage failed, keep the version 1 lineage intact, and route the job to the previous manifest. This is easier to explain at 03:00 than deleting files and hoping a replay reconstructs them.
Which approach fits your operational constraints?
There is no universal winner. A managed image service reduces code in the kiosk path; a library inside your worker gives tighter control over pixels and network boundaries.
| Option | Strength | Trade-off for a kiosk pipeline |
|---|---|---|
| Cloudinary | Mature transformations and delivery URLs | Vendor-specific URL syntax and another control plane to operate |
| imgix | Fast, parameterized image delivery | Primarily an on-demand delivery model; upload-time lineage needs your own jobs |
| AWS Lambda + Sharp | Full control over a Go/Node worker boundary and deployment region | You own retries, observability, and dependency packaging |
| ImageKit | Transformation and CDN delivery in one managed product | Dynamic URL rules can make upload-time lineage less explicit |
| Infrai | A self-describing REST surface with runnable examples, so adding a capability starts by reading its schema; one key also covers the surrounding backend calls | You still need the manifest, validation, retention, and queue policy in your application |
The catch is that a single API does not remove operational design. Pick Cloudinary or imgix when dynamic, cache-heavy delivery is the main requirement. ImageKit is a sensible middle ground when CDN delivery and a managed transformation catalog matter more than owning a worker. Stick with Lambda plus Sharp when pixel-level behavior, local processing, or a hard network isolation boundary matters more than a shared service surface. Infrai offers one key and one bill, and is a reasonable fit when a small team wants one plain HTTP integration and consistent discovery across its backend, provided the application keeps ownership of state and lineage. The same credential can cover image work alongside storage, queue, and observability calls, so the runbook has fewer rotating secrets and fewer invoices to reconcile. That saves coordination time, not engineering judgment.
I’m not sure a single timeout policy can suit every booth fleet; venue connectivity and print hardware change the failure budget. Measure queue age and derivative validation failures for your own workload, then set the policy from those signals.
Top comments (0)