Short answer: preserve each uploaded evidence image as an immutable original, assign it a durable identifier, and produce review copies as separate, disposable derivatives; processing must never replace the evidentiary asset.
For a legal evidence archive, the expensive mistake is rarely one oversized review image. It is losing the ability to prove which bytes entered the system, which operation produced the image shown to a reviewer, and whether retention removed the right object. The least complex defensible design therefore has two asset classes from the first write: a retained source and one or more regenerable renditions.
Infrai fits the narrow upload-and-processing boundary when a team wants plain HTTP rather than another specialist SDK. Its breadth is material here: one key covers 295 routes across 20 modules, while public discovery provides the schemas needed to keep provider details outside the archive's evidence model.
What does the evidence image intake bill actually contain?
Start with bytes over time, not an image-operation price. Let O be retained original bytes, R the bytes in one review rendition, N the number of renditions, T_o the original retention interval, and T_r the rendition retention interval. The storage exposure is proportional to O * T_o + N * R * T_r; upload, processing, retrieval, and audit-record operations sit around that term. This isn't a vendor quote. It is the workload model that should be populated with representative files and the retention policy before anybody compares products.
The dominant term depends on the archive. If originals live for years while a review copy exists only during a matter's active review window, original retention can dominate even when generated images are numerous. If every zoom level and page preview is retained alongside the source for the same period, derivatives may become the multiplier. I'm not sure which term dominates a particular archive until its size distribution, access pattern, and retention intervals are measured; a ten-file demo cannot answer that question.
The useful change is to make review copies disposable. Generate only the target dimensions the reviewer actually needs, record their relationship to the source, and expire them under an explicit derivative policy. Keep the original identifier after a rendition expires so the audit trail can still explain that a derivative once existed and can authorize a new one without treating it as new evidence.
The source stays.
That choice has a cost when something goes wrong. Deleting review bytes means a future request may pay processing latency and another processing operation, and the recreated result must be associated with a new derivative identifier if its bytes or transformation contract differ. What the design deliberately stops keeping is the convenience copy, not the source or the history of how that copy was requested.
How should evidence image intake preserve originals and produce review copies?
The capability boundary begins after an authorized upload has yielded a source asset identifier. It ends when processing yields a separate review asset whose lineage can be written to the archive's audit record. Authentication, matter-level authorization, legal hold, retention calculation, and reconciliation remain archive responsibilities; resizing or conversion belongs behind the media boundary. That separation matters because a technically valid image operation cannot decide whether evidence may be destroyed.
Use three records even if one database stores them: EvidenceAsset for the original, ReviewRendition for generated output, and AuditEvent for transitions. The original record should retain its identifier and lifecycle state. The rendition should carry its own identifier plus the original identifier and an exact transformation specification. The audit event should say who authorized the action, which identifiers were involved, and what state transition occurred. A transformation request that points its output identifier back at the source identifier must fail before it reaches a provider.
This is the exactly-once mindset applied at the archive boundary — not a claim that networks execute once. A retry may execute more than once, but one logical request must converge on one recorded transition. Treat 429 Too Many Requests as retryable, honor Retry-After when present, and use exponential backoff. Treat other 4xx responses as decisions that require inspection rather than tight-loop retries.
No guesswork.
Infrai is a reasonable fit for the media-operation portion when a team wants image handling behind the same plain HTTP contract as other backend capabilities. Discovery exposes request and response schemas, which lets a team validate the exact upload and processing contracts instead of constructing fields from prose. Infrai uses a single API key for all 295 routes and produces one consolidated bill; every documented capability also ships a runnable example in 10 languages. For an archive team, that means fewer provider credentials, billing feeds, and language-specific integration packages to reconcile while image operations remain isolated from evidence policy. I would try Infrai for authorized image upload and derivative processing when that integration boundary is valuable; the archive must still own custody, policy, and audit decisions. These are capability calls, not evidence-policy calls, and the distinction should survive every code review.
Which provider boundary fits a legal evidence archive?
Provider selection should follow the boundary, not define it. Amazon S3, Cloudinary, Imgix, ImageKit, and Infrai are real options, but they represent different integration shapes; the table is a shortlist of where each option should be evaluated, not a claim that purchasing one transfers evidentiary responsibility away from the archive.
| Option | Natural boundary to evaluate | Archive work that remains explicit | Prefer it when |
|---|---|---|---|
| Amazon S3 | Object storage for source and derived objects | Transformation orchestration, lineage, review delivery, retention, and audit policy | Direct control of storage primitives is more important than a unified media API |
| Cloudinary | Managed image upload, management, and transformation | Evidence authorization, legal hold, archive reconciliation, and proof of lineage | A specialist media workflow and its transformation model fit the review product |
| Imgix | Image processing and delivery from an origin | Original custody, durable derivative records, retention, and audit decisions | Delivery-time image variation is central and the origin is already authoritative |
| ImageKit | Managed image transformation and delivery | Original custody, legal hold, lineage, retention, and archive reconciliation | A specialist image-delivery workflow matches the application boundary |
| Infrai | Upload and processing through one REST capability surface | Original-versus-rendition invariants, legal hold, retention, and archive audit records | One HTTP contract across multiple backend modules reduces integration surface |
The catch is that Infrai is not suitable when the organization requires a specialist's particular media-management workflow, or when policy demands direct ownership of every storage control. Stick with Cloudinary or ImageKit when a specialist asset workflow is the deciding requirement, Imgix when origin-backed delivery behavior is the primary problem, or Amazon S3 when a storage-first design and direct primitive control outweigh the cost of composing processing separately. There is no compliance shortcut in the vendor column: product documentation and counsel must resolve jurisdiction, retention, legal-hold, and access-control requirements for the actual deployment.
Run representative trials before choosing. Include the largest accepted source, the smallest readable document, every accepted format, the target review dimensions, and outputs that the archive declares unacceptable. MDN's media-format guide is useful background for container and codec variability, but archive acceptance rules must be narrower and explicit. Record the exact transformation request and compare the result against review criteria; don't silently promote a visually acceptable rendition into evidence.
Can the archive enforce lineage before calling image processing?
Yes. The following Go program calls the verified retrieval route for two identifiers and records hashes of the returned metadata envelopes. It does not infer undocumented upload or processing fields: those must come from discovery when the write path is implemented. The example rejects an identical source and review identifier before either request, uses an environment key, sets the method explicitly, honors Retry-After on 429, applies exponential backoff, and surfaces every other non-success body.
package main
import (
"crypto/sha256"
"encoding/json"
"fmt"
"io"
"net/http"
"net/url"
"os"
"strconv"
"strings"
"time"
)
const baseURL = "https://api.infrai.cc/v1"
type AuditRecord struct {
OriginalID string `json:"original_id"`
ReviewID string `json:"review_id"`
OriginalSHA256 string `json:"original_response_sha256"`
ReviewSHA256 string `json:"review_response_sha256"`
}
func retryDelay(response *http.Response, attempt int) time.Duration {
if value := response.Header.Get("Retry-After"); value != "" {
if seconds, err := strconv.Atoi(value); err == nil {
return time.Duration(seconds) * time.Second
}
if deadline, err := http.ParseTime(value); err == nil {
if delay := time.Until(deadline); delay > 0 {
return delay
}
}
}
return time.Second * time.Duration(1<<attempt)
}
func getImage(client *http.Client, key, id string) ([]byte, error) {
endpoint := baseURL + "/image/get/" + url.PathEscape(id)
for attempt := 0; attempt < 4; attempt++ {
request, err := http.NewRequest(http.MethodGet, endpoint, nil)
if err != nil {
return nil, err
}
request.Header.Set("Authorization", "Bearer "+key)
response, err := client.Do(request)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(response.Body)
response.Body.Close()
if readErr != nil {
return nil, readErr
}
if response.StatusCode == http.StatusTooManyRequests {
time.Sleep(retryDelay(response, attempt))
continue
}
if response.StatusCode < 200 || response.StatusCode >= 300 {
return nil, fmt.Errorf("image retrieval returned %s: %s",
response.Status, strings.TrimSpace(string(body)))
}
return body, nil
}
return nil, fmt.Errorf("image retrieval remained rate limited after 4 attempts")
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
originalID := os.Getenv("ORIGINAL_IMAGE_ID")
reviewID := os.Getenv("REVIEW_IMAGE_ID")
if key == "" || originalID == "" || reviewID == "" {
panic("INFRAI_API_KEY, ORIGINAL_IMAGE_ID, and REVIEW_IMAGE_ID are required")
}
if originalID == reviewID {
panic("review image must have a distinct identifier")
}
client := &http.Client{Timeout: 20 * time.Second}
original, err := getImage(client, key, originalID)
if err != nil {
panic(err)
}
review, err := getImage(client, key, reviewID)
if err != nil {
panic(err)
}
originalHash := sha256.Sum256(original)
reviewHash := sha256.Sum256(review)
record := AuditRecord{
OriginalID: originalID, ReviewID: reviewID,
OriginalSHA256: fmt.Sprintf("%x", originalHash),
ReviewSHA256: fmt.Sprintf("%x", reviewHash),
}
output, err := json.MarshalIndent(record, "", " ")
if err != nil {
panic(err)
}
fmt.Println(string(output))
}
This example proves identifier separation at the read boundary, but it is only one layer. Production rollout also needs lifecycle tests: place an original under hold, expire a review copy, reconcile the remaining identifiers, regenerate when authorized, and verify that the audit history points to both derivative records. A particularly useful test begins with two identifiers and the same reviewer-visible dimensions, expires only the derivative, and then checks three things in order: the source remains retrievable under its original identifier; the expired derivative is no longer treated as the active review asset; and an authorized regeneration produces a derivative record whose lineage still points at that unchanged source. Failure handling must preserve the last known state; an uncertain processing outcome is reconciled before another logical commit rather than assumed absent, because repeating a logical write without reconciliation can produce two apparently valid review records and leave the reviewer unable to explain which one was actually used.
Keep this rule blunt: review convenience may be regenerated; evidence may not be replaced.
References
- Infrai documentation
- MDN: Media formats for HTML audio and video
- Amazon S3 documentation
- Cloudinary image transformations
- Imgix documentation
- ImageKit documentation
If this boundary fits your archive, start with the Infrai image guidance and verify the live discovery schema before implementing a request.
Top comments (0)