Behind the Build: How Vyso Was Designed to Scale

A good DAM platform organizes your files. It also needs to remain operable as the library grows.

When we built Vyso, we wanted an asset library that could accommodate growing content and evolving use cases. That meant looking beyond the speed of an initial upload or search. Storage, ingestion, background enrichment, indexing, management requests and media delivery place different demands on a system.

Designing for scale means separating those responsibilities and controlling expensive work, so growth in one workload does not unnecessarily become every other subsystem's problem. The architecture explains how Vyso approaches that growth. Performance at a particular workload still needs measurement.

Built for Scale, Not Just Speed

Optimizing for short-term speed says little about performance under long-term load. A quick response from a small library does not establish how the system behaves during a sustained upload burst, a growing enrichment backlog or repeated requests for new image representations.

DAM scalability has several dimensions. Storage grows with the bytes retained. Asset count grows the number of records and associated context. Ingestion rate determines how much new work arrives. Enrichment and indexing consume processing capacity. Search and management traffic create query work. Media delivery adds another pattern of requests and bandwidth use.

A large library is not the same as high media traffic. A team can store many assets while serving relatively few images publicly. A website with a small set of source images can receive substantial delivery traffic. Neither workload can be described adequately by the number of files alone.

Total library size is also different from ingestion rate. Existing assets do not all become new uploads every time someone opens the library. Conversely, a smaller workspace can create processing pressure by submitting new files faster than enrichment can finish.

These distinctions explain why responsibilities should have different execution paths. A request for an existing image should not require new descriptive enrichment. Browsing a collection should not require reading every source binary. The deeper operational questions are covered in DAM scalability and large asset libraries; the architectural question is how to keep those workloads separable.

Modular by Design

Teams evolve. So do workflows. The DAM a team needs today can differ from what it needs a year from now. Modularity helps when a responsibility can change without forcing every other responsibility through the same execution path.

Vyso's original-first design provides one such boundary. The uploaded source remains intact while technical properties, generated descriptive context and search indexes are created around it. Updating that context does not require replacing the original file. A requested delivery representation is another output from the source, rather than a new authoritative original for each resize.

Upload handling stores the source and creates its library record before all downstream enrichment finishes. Validation and storage still take request time, but supported-image enrichment and search updates run through background jobs. An uploaded asset, a fully enriched asset and an indexed asset are different conditions.

That separation is visible in failure handling too. If storage succeeds but publishing the background job fails, the upload response can report that the asset is stored while processing still needs to be queued. A successful file transfer should not be interpreted as proof that descriptive retrieval is ready.

The public interfaces expose another responsibility boundary. The Developer API at https://api.vyso.io/v1 manages library operations such as assets, uploads, metadata, collections, search and transformation presets. CDN delivery at https://cdn.vyso.io serves the requested media representation.

The application or user chooses the source and required output. Delivery applies an explicit transformation chain or preset. It does not need to manage a collection or make a campaign decision to return that image.

Separate hostnames identify different contracts; they do not prove independent infrastructure. Background processing has its own worker boundary, but these responsibilities still depend on shared resources. Modularity here means separation of responsibilities, not a claim that every workload already has its own independently scaled service.

It also does not establish an arbitrary plugin or rules platform. A new upload policy, personalization decision or integration needs its own implementation. Those capabilities do not appear automatically because the asset pipeline has defined stages.

Performance as Workloads Grow

Search, uploads and image delivery do different kinds of work. Keeping each operation bounded where possible gives the system clearer behavior under load.

Bound library browsing and retrieval

The asset list endpoint supports page limits, offsets and cursors, and validates a maximum page size. It returns a page of asset records with pagination information instead of requiring a client to download the entire library for normal browsing.

A page-size limit bounds returned records, not every cost behind the request. Filtering, sorting and counting matching assets still require database work. Pagination therefore provides a useful boundary without promising constant query time as the library grows.

Use the paginated asset list for normal library browsing. Full-text and hybrid search are retrieval paths for indexed discovery rather than replacements for paginated browsing. Search context can evolve separately from binary storage, but retrieval still consumes database capacity and, where semantic querying is used, model capacity.

Control uploads and background work

The documented upload endpoint accepts one file per request and applies a configurable size limit. Oversized uploads can receive HTTP 413. This gives individual requests a defined boundary; it says nothing about guaranteed throughput across many concurrent uploads.

Background processing limits how much work is active at once, with controls for job concurrency and memory-heavy image inspection. Metadata generation and search-index updates run as distinct stages, allowing them to progress through their own queues.

Moving work into a queue changes when it runs. It does not remove its cost. If incoming work consistently exceeds completion capacity, the backlog grows. More queued jobs are not evidence of more completed enrichment, and raising concurrency can increase memory pressure or demand on downstream services.

Make overload behavior explicit

Scalability includes deciding what happens when demand exceeds the rate a component should accept. Vyso's rate-limit documentation describes configurable request buckets, with separate settings for uploads and public media delivery. Requests over the applicable limit receive HTTP 429 and a Retry-After header.

The HTTP specification defines 429 as rate limiting. A client should respect the returned retry interval rather than repeatedly submitting the same request immediately. Controlled request rates give overload a defined response; they do not establish an unlimited capacity ceiling.

Adding application replicas does not automatically solve load coordination. Request limits and shared dependencies still need explicit coordination. Horizontal scaling cannot be established merely by starting another process.

Reuse requested delivery representations

Vyso delivery starts with the preserved source and applies the requested transformation chain or preset. The response is cacheable, allowing a cache to reuse that representation on later equivalent requests. A cache hit can avoid repeating origin transformation work; an uncached representation still needs source access and processing.

This is the purpose of HTTP response caching: reuse a prior response when the cache's rules permit it. It is not a guarantee that every request hits a cache or that generating a new output has no latency.

Keep a consistent URL for an unchanged representation. Requesting many slightly different outputs creates more representations to process and cache. Source or preset changes also need an invalidation decision. The caching documentation explains this boundary without making cache-hit or throughput guarantees.

Architecture can explain how a system is intended to accommodate growth. It cannot prove a particular latency, throughput or asset-count ceiling without measurement. Upload completion, enrichment completion, search response time and delivery from a warm or cold cache are different observations. A performance claim should say which one was measured and under what workload.

Future-Proof by Intent, Not Prediction

Tech stacks change. APIs evolve. Standards shift. Designing for that change means reducing the cost of modifying a responsibility while keeping the source assets usable.

Preserving originals leaves the system a source from which to request other supported representations later. An explicit transformation chain records the technical treatment being requested. Changing a website's required output can therefore involve changing its delivery recipe without making that output the library's new original.

Generated metadata and indexed search context can also change around the source. A change to descriptive processing or retrieval still requires engineering work and, in some cases, rebuilding derived context. The boundary makes that work identifiable; it does not make it automatic or free.

The distinction between library management and delivery lets an application use the appropriate contract for each responsibility. It does not promise support for unknown future formats, standards or AI capabilities. New support must be implemented and validated.

This is also where a horizontal-scaling claim needs care. A separate worker service is a concrete boundary, but horizontal scaling also requires coordination across workers and shared storage, database and broker dependencies. Long-term adaptability means having clear places to make those changes, with coordination and performance checked explicitly.

Reliability, Privacy, and Trust at the Core

As a DAM becomes part of daily operations, teams need to know which actions succeeded, which work is still pending and which access boundary applies.

The background pipeline uses RabbitMQ queues declared durable, persistent job messages and publisher confirmations. Workers acknowledge a delivery after its handler returns successfully. Failed processing can be requeued, with a configurable worker-side wait before requeueing. That wait is not a durable retry schedule. Storage success, job publication and job completion are separate events.

RabbitMQ's acknowledgement documentation distinguishes broker confirmation from consumer completion and explains why redelivery must be handled. In Vyso, these mechanisms support recovery from interrupted work, and a redelivered job can run more than once. They do not guarantee exactly-once execution or completion within a fixed time. A repeatedly failing dependency still needs operational attention.

API errors also distinguish missing authentication, invalid requests, unavailable resources, conflicts and throttling. That gives a calling application more information than a generic success or failure signal. Storage success, queue acceptance and processing completion should remain distinguishable in that application's handling.

Vyso's Security page documents HTTPS/TLS, Clerk authentication and account or workspace scoping for authenticated management operations. These controls should be described precisely. Workspace-scoped management does not establish asset-level RBAC, licensing enforcement or private signed CDN links. The media-delivery surface is public by design.

The Privacy Policy explains how uploaded content supports library, search, transformation and delivery features. It states that Customer Content is not used to train general-purpose foundation models outside the customer's workspace, and describes limited sharing with external providers when needed for a requested feature.

Operational delivery metrics are also narrower than complete usage history. The backend has request and byte metrics for deliveries metered by its handlers. Those events do not identify every downstream copy, every person who uses a downloaded file or every response served wholly from an edge cache.

Trust in a long-term platform depends on making these boundaries understandable and checking behavior as workloads change. The architecture provides concrete places to investigate storage, queues, retrieval and delivery. Uptime commitments and measured capacity require their own evidence.