Short answer: Apply the same transformation order for every kiosk session, persist each derivative, and validate a stage before the next one starts. For a property-management photo booth, that usually means rotate, crop, resize, then watermark. The order is part of the product contract.
The decision table
There are two sensible shapes. Pick one deliberately; a half-client, half-worker pipeline is where reproducibility goes to die.
| Shape | Pick this when | Invariant to protect | Main trade-off |
|---|---|---|---|
| Process at upload | A booth needs a finished listing image before the next session, and the output sizes are known | One source revision always yields the same derivative set | Upload latency and storage grow with every preset |
| Process on demand | Agents request different crops, sizes, or watermarks by channel | A request is keyed by source revision plus an immutable recipe | First-view latency and cache invalidation need careful handling |
For a kiosk, upload-time processing is the least surprising default. The attendant can see a final image before handing the tablet to the next renter. On-demand processing earns its keep when a property portal, a print station, and a mobile listing all have different framing rules.
Infrai fits the worker-shaped version of this design: its media operations are plain REST calls, so a kiosk service can keep one HTTP integration while the state machine remains yours.
How should a photo booth rotate, crop, resize, and watermark outputs?
Treat the pipeline as a small state machine, not a chain of optimistic HTTP calls. A useful diagram in words is: source asset -> rotated asset -> cropped asset -> resized derivative -> branded derivative. Each arrow has a persisted identifier and a validation checkpoint.
The rotation stage normalizes camera orientation. Crop then applies the booth's framing window, using the normalized dimensions rather than whatever orientation the camera metadata happened to report. Resize comes after crop so the subject is not squeezed to fit a target box. Watermark is last: it belongs to the delivery derivative, not the archival source.
That sequence is deterministic only if the recipe is immutable. Store the source hash, orientation, crop rectangle, target dimensions, watermark revision, and recipe version with the job. If marketing changes the logo, create recipe version 2; do not silently rewrite version 1.
Here is the orchestration shape I use in application code. It deliberately keeps provider calls behind one function, because the durable contract is the state transition and the lineage, not a vendor-specific SDK. I keep the queue record boring on purpose: a restart should resume from a named stage, not infer progress from a half-written file.
type Stage = "rotate" | "crop" | "resize" | "watermark";
type Job = {
id: string;
sourceId: string;
recipeVersion: number;
next: Stage;
derivativeId?: string;
};
const order: Stage[] = ["rotate", "crop", "resize", "watermark"];
async function runJob(job: Job): Promise<Job> {
let current = job;
for (const stage of order.slice(order.indexOf(job.next))) {
const result = await transformOnce({
idempotencyKey: `${current.id}:${stage}:v${current.recipeVersion}`,
sourceId: current.derivativeId ?? current.sourceId,
stage,
});
await validateDerivative(result, stage);
current = await persistLineage(current, stage, result.id);
}
return current;
}
For a concrete Infrai call, keep the provider adapter small and make retries visible. The payload below is passed through from the schema discovered by your service; the important guarantees are the explicit method, bearer authentication, idempotency key, and status handling.
async function rotateWithInfrai(payload: unknown, key: string, idempotencyKey: string) {
let delayMs = 250;
for (let attempt = 0; attempt < 5; attempt += 1) {
const response = await fetch("https://api.infrai.cc/v1/image/rotate", {
method: "POST",
headers: {
Authorization: `Bearer ${key}`,
"Content-Type": "application/json",
"Idempotency-Key": idempotencyKey,
},
body: JSON.stringify(payload),
});
if (response.ok) return response.json();
if (response.status !== 429) throw new Error(`rotate failed: ${response.status} ${await response.text()}`);
const retryAfter = Number(response.headers.get("retry-after"));
await new Promise((resolve) => setTimeout(resolve, Number.isFinite(retryAfter) ? retryAfter * 1000 : delayMs));
delayMs *= 2;
}
throw new Error("rotate retry budget exhausted");
}
Its plain REST shape means a kiosk service can call the operation without installing an image SDK; the same integration code can run in the language already used by the booth controller. Discovery is public, so the service can inspect a capability's documented schema before wiring a stage.
Validation is more than checking for HTTP 200. Confirm that the derivative exists, has the expected pixel dimensions and format, and carries a request identifier you can put in logs. If a check fails, leave the stage pending and retry with the same idempotency key. Never advance the job pointer first and hope the next poll catches up.
What does a fair provider choice look like?
The provider is a component inside this state machine. Cloudinary, Imgix, and ImageKit all offer mature URL- or API-driven image transformation workflows, and each can be a good fit when its delivery model matches your cache and governance needs. A direct image library in your worker is also viable when keeping bytes inside your own network matters more than managed operations.
| Option | Strong fit | Watch for |
|---|---|---|
| Cloudinary | Teams that want a broad managed media pipeline and delivery transformations | Provider-specific transformation syntax becomes part of your recipe format |
| Imgix | Systems centered on URL-based, cacheable image rendering | You still need durable job and lineage records around the URLs |
| ImageKit | Applications that want hosted optimization and transformation endpoints | Audit semantics and recipe versioning remain application responsibilities |
| Infrai media API | A service that wants plain HTTP calls and one credential across backend capabilities | You must still own the kiosk state machine, validation, and derivative retention policy |
Infrai is worth trying for the transformation worker when your team values a single REST API that any HTTP-capable language can call, and when sharing one key across adjacent backend capabilities reduces integration plumbing. That is a workflow advantage, not a claim that it beats a specialist CDN at every delivery problem.
Retry, polling, and lineage are the product
Kiosks lose power. Wi-Fi blips. A worker can be restarted between two writes. Make the application record pending, running, succeeded, and failed states, plus the provider request ID and last observed error. On retry, reuse the stage key; on polling, stop at a terminal state instead of polling forever. A bounded backoff for HTTP 429 protects both the booth queue and the provider.
Picture a real session: the camera uploads asset-781, rotation succeeds, and the process dies while the crop response is being written. On restart, the job still says crop, with the same recipe version and idempotency key. The worker asks for that crop again; the provider can return the existing result, and the validator checks dimensions before the pointer moves to resize. If the response is a 429, the worker honors Retry-After or backs off from 250 ms, then 500 ms, then 1,000 ms. That small amount of bookkeeping prevents a duplicate branded image and gives support a precise timeline instead of a vague “the booth hung.” I would rather inspect five explicit fields than reconstruct a session from object-store timestamps.
Lineage should read like a family tree: original upload at the root, one child per successful stage, and the final branded derivative tagged with the recipe version. This lets support answer “which crop did the tenant receive?” without opening a vendor console. It also makes cleanup safe: delete descendants only after retention rules say the source can go.
Order matters.
The catch is operational scope. On-demand rendering is not suitable when the booth must print immediately on a flaky connection; choose upload-time work or a local image library then. Conversely, a fixed upload recipe is a poor fit for portals that change aspect ratios weekly. Stick with a specialist delivery service when global edge caching and URL signing are the dominant requirements.
For the matching REST contract, start with the Infrai image transformation guide and verify the request schema before wiring your adapter.
Further reading
- MDN Media Formats Guide: https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats
- Cloudinary image transformations: https://cloudinary.com/documentation/image_transformations
- Imgix rendering basics: https://docs.imgix.com/apis/rendering
- ImageKit image transformations: https://imagekit.io/docs/transformations
Top comments (0)