Skip to main content
Galactic Core is designed to scale horizontally under load and to degrade gracefully rather than fail outright. This page covers the properties that matter once traffic is heavy: how the platform scales, how it limits load, and how it behaves when something goes wrong.

​
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.

Isolation as sharding

Each deployment runs on its own stack, so adding tenants adds independent capacity rather than contending for a shared database — per-deployment isolation is horizontal sharding by design. See Data Model.
In short, the layers that are cheap to scale — edge compute, cache, replicas — carry the load, and the primary database, the one layer that must stay consistent, sees only writes and genuine cold reads.

​
Controlling load

Layered limits protect the platform and every tenant on it, 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 a 429 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. For a catalog, a slightly-stale page is almost always preferable to a failed one. The caching directives are covered in The Caching Pipeline.
2

Safe retries

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

Consistent 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

No overselling in a rush on limited stock

When tens of thousands of shoppers try to reserve the same item at once — a limited drop, a flash sale — each unit is claimed by exactly one shopper. Stock reservation is serialized per item at the edge: the decision to grant or decline a reservation is made in memory, close to the shopper, without a database round trip, so a single hot item sustains tens of thousands of reservation decisions per second and a shopper who missed out is told instantly rather than after a slow wait. The item’s stock can never be reserved below zero, no matter how many requests arrive at the same instant. A reservation holds the stock for a short window and is released automatically if the shopper does not complete checkout, returning the units to available inventory.
5

Isolated failures

Because each deployment is physically isolated, one tenant’s load spike or incident cannot degrade another’s — there is no shared database or compute to contend for.

​
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. Per-deployment isolation applies here too: each deployment’s backups are its own, so a restore 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 — [email protected].

The Caching Pipeline

The cache tiers that carry the read load.

Data Model & Multi-tenancy

How per-deployment isolation keeps tenants separate and adds capacity.