Scaling
Stateless edge compute
Requests are handled by stateless compute in hundreds of locations worldwide, with no per-instance
state and no configuration to scale. Capacity is added at the edge automatically as traffic rises,
and the model is identical for one merchant or a marketplace of thousands.
Cache-served reads
Reads are the bulk of commerce traffic and are served from cache, so a surge of shoppers browsing
and checking out resolves to a small number of database queries rather than millions. See
Caching.
Regional read replicas
The database runs a primary alongside regional read replicas, so read-heavy traffic is served from a
replica close to the shopper and the primary is reserved for writes. Reads scale out; writes stay
consistent.
Dedicated stacks add capacity
A tenant on a dedicated deployment runs on its own stack, so it adds independent capacity rather than
contending for a shared database — isolation doubling as horizontal sharding. On the shared platform,
the edge, cache, and replica layers carry the load for everyone. See Data Model.
Stores on a platform operated by an agency scale exactly as described here — they are ordinary
stores. What differs is the agency’s own reporting, which spans every merchant it owns, and the option
to move a single large merchant to its own deployment without moving the rest. See
Growing the platform.
Limits on load
Limits are enforced at the edge, before a request reaches the workers or the database. Rate limits are tiered by key type: publishable keys are limited per IP and per key, secret keys per key, with tighter limits on sensitive endpoints such as payments and authentication. A throttled request receives a429 with a rate_limited code rather than a dropped connection. Usage quotas are counted
atomically per store, so plan limits and overage are metered exactly even under concurrent traffic from
many locations at once. The Core Concepts page documents the response contract.
Graceful degradation
Under stress the platform aims to return a slower or slightly-stale response rather than an error.1
Stale responses during an incident
Public catalog responses carry
stale-if-error, so if the origin has a bad moment the edge keeps
serving the last-known-good response instead of a 500. The caching directives are covered in
The Caching Pipeline.2
Retries that cannot duplicate
Order creation is idempotent: an
Idempotency-Key ensures a retried request never creates a
duplicate, so a client whose response was lost in transit can retry without risk.3
Money math under concurrency
Totals, discounts, and gift-card redemption are computed in atomic database functions, so
concurrent orders for the same customer do not produce lost updates or inconsistent balances.
4
Contention on a single item
When tens of thousands of shoppers reserve the same item at once — a limited drop, a flash sale —
each unit is claimed by exactly one shopper. Reservation is serialized per item at the edge and
decided in memory, without a database round trip, so a shopper who missed out is answered
immediately and the item can never be reserved below zero however many requests arrive at the same
instant. A reservation holds the units for a short window and returns them to available inventory
if checkout is not completed. The full mechanism is in
Marketplaces at Scale.
5
Failures that reach one tenant
A tenant on a dedicated deployment is physically isolated, so its load spike or incident cannot reach
another tenant — there is no shared database or compute to contend for. On the shared platform, the
per-store rate limits and atomic quotas above keep one store’s traffic from degrading its neighbours.
Asynchronous work
Work that need not block the response runs on durable queues, so a transient failure is retried rather than lost.Outbound webhooks
Deliveries retry on an exponential backoff that spans minutes to a couple of days across several
attempts, and an endpoint that keeps failing is disabled by a circuit breaker so it cannot hold up
the pipeline. See Webhooks.
Notifications and indexing
Merchant notifications, onboarding sequences, and search and recommendation indexing run on durable
queues drained on a schedule, with retries, delayed sends, and multi-producer fan-in, entirely off
the request path.
Backups and recovery
The database is backed up continuously, not just on a nightly snapshot. Alongside regular full backups, a write-ahead log captures every committed change, which makes point-in-time recovery possible: the database can be restored to any moment within the retention window — the instant before an accidental bulk delete or a bad migration, for example — rather than only to the last snapshot. A dedicated deployment’s backups are its own, so a restore there affects one tenant and never reaches across to another.Planning for a specific scale or availability target? We are glad to review the architecture against
your traffic profile and reliability requirements —
support@tybritelabs.com.
The Caching Pipeline
The cache tiers that carry the read load.
Data Model & Multi-tenancy
How shared-platform and dedicated-deployment isolation keep tenants separate.