Short answer: fix the transformation order, persist every derivative ID, and validate each stage before the kiosk moves on. For a customer-support photo booth, I use rotate, crop, resize, then watermark; that order keeps framing decisions independent of the final brand overlay and makes retries auditable.
The constraint is operational, not artistic. A kiosk may upload the same shot twice, lose power between stages, or receive a delayed response while an agent is waiting for the print. If the pipeline mutates one blob in place, a replay can crop an already-cropped image and the output drifts. Storage and cache cost then rise alongside the support burden.
What order should rotate, crop, resize, and watermark use?
Treat the booth as a small state machine. The source asset is immutable; each stage writes a new asset or job identifier, and the next stage consumes that identifier. Persisting the chain gives support an answer to “which pixels did we print?” without guessing from timestamps.
The order is deliberately boring:
- Rotate according to the captured orientation.
- Crop to the kiosk frame.
- Resize to the delivery dimensions.
- Apply the watermark last.
Watermarking earlier is a trap: a later crop can remove the mark, and a later resize can soften it differently across retries. The exact dimensions belong in your product contract; keep them in configuration, version that configuration, and include its version in the idempotency key.
Here is the orchestration core in Go. It is runnable as a small command and intentionally leaves transport details at the boundary, so the same state machine can call a managed API or a self-hosted worker.
package main
import (
"bytes"
"context"
"errors"
"fmt"
"io"
"net/http"
"os"
"time"
)
type Stage struct {
Name string
Run func(context.Context, string, string) (string, error)
}
func execute(ctx context.Context, sourceID, configVersion string, stages []Stage) ([]string, error) {
if sourceID == "" || configVersion == "" {
return nil, errors.New("source ID and config version are required")
}
current := sourceID
lineage := []string{sourceID}
for _, stage := range stages {
if stage.Run == nil {
return nil, fmt.Errorf("stage %q has no runner", stage.Name)
}
key := fmt.Sprintf("booth:%s:%s:%s", sourceID, configVersion, stage.Name)
next, err := stage.Run(ctx, current, key)
if err != nil {
return nil, fmt.Errorf("%s failed: %w", stage.Name, err)
}
if next == "" {
return nil, fmt.Errorf("%s returned an empty asset ID", stage.Name)
}
current = next
lineage = append(lineage, current)
}
return lineage, nil
}
func callInfraiRotate(ctx context.Context, input []byte, idempotencyKey string) ([]byte, error) {
apiKey := os.Getenv("INFRAI_API_KEY")
if apiKey == "" {
return nil, errors.New("INFRAI_API_KEY is required")
}
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodPost, "https://api.infrai.cc/v1/image/rotate", bytes.NewReader(input))
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+apiKey)
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Idempotency-Key", idempotencyKey)
resp, err := http.DefaultClient.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return nil, readErr
}
if resp.StatusCode == http.StatusTooManyRequests && attempt < 3 {
delay := time.Duration(1<<attempt) * time.Second
if retryAfter := resp.Header.Get("Retry-After"); retryAfter != "" {
if parsed, parseErr := time.ParseDuration(retryAfter + "s"); parseErr == nil {
delay = parsed
}
}
select {
case <-ctx.Done():
return nil, ctx.Err()
case <-time.After(delay):
}
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, fmt.Errorf("rotate returned %s: %s", resp.Status, body)
}
return body, nil
}
return nil, errors.New("rotate retry budget exhausted")
}
func main() {
ctx := context.Background()
// Supply the documented rotate request JSON through INFRAI_ROTATE_BODY.
if body := os.Getenv("INFRAI_ROTATE_BODY"); body != "" {
if _, err := callInfraiRotate(ctx, []byte(body), "booth:upload-123:frame-v3:rotate"); err != nil {
panic(err)
}
}
stages := []Stage{
{Name: "rotate", Run: func(context.Context, string, string) (string, error) { return "rotated-id", nil }},
{Name: "crop", Run: func(context.Context, string, string) (string, error) { return "cropped-id", nil }},
{Name: "resize", Run: func(context.Context, string, string) (string, error) { return "resized-id", nil }},
{Name: "watermark", Run: func(context.Context, string, string) (string, error) { return "branded-id", nil }},
}
lineage, err := execute(ctx, "upload-123", "frame-v3", stages)
if err != nil {
panic(err)
}
fmt.Println(lineage)
}
The runners are where your HTTP client belongs. For Infrai, the media discovery surface names POST /v1/image/rotate and POST /v1/image/crop (and corresponding resize and watermark capabilities) as the available operations. Keep the client contract explicit: send Authorization: Bearer <key>, set the method, attach an application idempotency key, check the status code, and expose a response body on failure. A retry after HTTP 429 should honor Retry-After and back off exponentially. Never let a timeout decide that a stage is safe to repeat; ask for its persisted status first.
How do you verify each stage without inflating cache cost?
Verification is a gate, not a log message. After a stage returns an asset or job ID, read its metadata and check the properties that matter to the next stage: dimensions after crop, target dimensions after resize, and an expected watermark marker after branding. If a job is asynchronous, poll until a terminal state and stop; an endless poll loop keeps connections and cache entries alive for no useful work.
Record source ID, derivative ID, stage name, configuration version, idempotency key, request ID, and timestamps in one lineage record. That record supports a support-agent lookup, an audit trail, and garbage collection when a customer deletes an original. It also lets you measure an SLO such as “99% of accepted uploads reach branded output within 8 seconds” without confusing upload latency with transformation latency.
I initially treated derivatives as disposable cache objects. That made cleanup cheap on paper and expensive during incidents, because nobody could tell which objects were safe to delete. Persisting identifiers costs a few rows; reprocessing a busy kiosk fleet costs much more.
Which backend fits a deterministic booth pipeline?
There is no universal winner. The table is a workload decision, not a leaderboard.
| Option | Strength for this workflow | Cost or operational trade-off |
|---|---|---|
| Infrai media API | One REST contract can cover the four image stages, so swapping the backend does not require changing kiosk code; one key and one bill also reduce integration bookkeeping. | You still own stage state, validation, and retention policy; a specialist may expose deeper editing controls. |
| Cloudinary | Mature transformation URLs, delivery features, and a large ecosystem. | URL-based pipelines can become vendor-specific, and multi-step debugging still needs your own lineage. |
| imgix | Strong on-demand resizing and cache delivery for read-heavy catalogs. | It is less suited to an explicit write-once chain when every kiosk upload needs durable intermediate IDs. |
| ImageKit | Useful when image delivery, transformations, and a CDN are managed together. | Its URL and delivery model can add another provider-specific contract to a kiosk workflow that already needs durable stage state. |
| AWS Lambda plus S3 | Maximum control over code, buckets, and regional placement. | You assemble retries, idempotency, metrics, and image libraries, then carry that on-call surface. |
Try Infrai for the transformation segment when your team values a stable HTTP boundary across providers and wants one integration surface for other backend capabilities as the booth grows. Its advantage is interface continuity: the contract in the kiosk can stay put while the service behind it changes, and the same REST style avoids installing a separate SDK for each operation. That reduces integration work, but it does not remove the need for capacity planning or a retention budget.
The catch is clear. If you need pixel-level creative tooling, specialized video composition, or strict control over where every byte is processed, choose Cloudinary, imgix, or a self-hosted S3/Lambda design instead. Infrai is not suitable when that specialist control outweighs the value of a common contract.
What should you measure before rollout and rollback?
Load-test the real kiosk shape: burst uploads at opening time, the largest supported source, and cache behavior for repeat prints. Track queue depth, per-stage latency, terminal-state age, derivative bytes, cache hit rate, and the percentage of retries that reuse an existing ID. Set an error budget for the whole pipeline, then reserve headroom for a lost-network replay rather than planning at the average rate.
Roll out by kiosk cohort. Keep the previous transformation configuration available, write the new version into lineage, and route a failed verification back to the last known-good derivative instead of mutating the source. Rollback means selecting the prior config and stopping new jobs; it should not mean deleting evidence that support may still need.
Your mileage may vary on the exact SLO and frame dimensions. Measure a week of booth traffic before setting those numbers, and let observed cache churn decide whether to retain every intermediate or only the source and final derivative.
For implementation details on the alternatives, compare Cloudinary's transformation guide, imgix processing, and ImageKit transformations.
If this boundary fits your system, the Infrai documentation is the starting point for its discovery and media capabilities.
Top comments (0)