1 · In-function concurrency
Fluid Compute reuses warm runtime capacity first, increasing efficiency and reducing unnecessary instance creation.
Performance & scale evidence
Scale CoreX automatically now, then increase the right constraint as demand grows.
CoreX separates software capability, current deployed capacity and provider-neutral scale-out potential. Runtime instances scale automatically; persistence, signer, network and queue capacity are increased only when evidence shows they are the binding constraint.
Adaptive capacity ladder
2 · Horizontal instances
When existing runtime capacity is insufficient, the compute layer can scale out automatically without changing CoreX authority or tenant semantics.
3 · Persistence
Each instance uses a bounded PostgreSQL pool. Database compute, IOPS and connection capacity are scaled separately when persistence becomes the constraint.
4 · Workers & queues
Backlog and queue age determine when bounded worker capacity should increase. Idempotency and retry governance remain unchanged.
5 · Signer & network
Signer quotas, bandwidth and external provider limits are treated as distinct constraints rather than as the CoreX software ceiling.
6 · Regional scale
Additional regions and read/verification capacity are introduced after data locality and persistence topology are measured, not by blindly duplicating write paths.
How capacity is evaluated
Current allocation
Executed workload throughput and latency on a named runtime, node shape and persistence configuration.
Scale-out envelope
Single-node evidence multiplied across additional nodes only with an explicit scale-efficiency assumption or measured distributed efficiency.
Effective ceiling
The minimum of compute, persistence, signer, network, queue and external-provider capacity.
Automatic refinement loop
Observe → classify → autoscale → refine the binding constraint → remeasure → freeze new evidence.
CoreX allows runtime-managed scaling automatically, but does not automatically purchase larger infrastructure or weaken safety controls. When measured demand reaches a persistence, signer, network or provider ceiling, that specific capacity is increased and the same benchmark is rerun.
Built-in scale primitives
Elastic runtime + bounded data plane
Fluid runtime scale, bounded PostgreSQL pools and adaptive bottleneck classification are active platform capabilities.
Leased workers + replay
Durable event delivery supports horizontal workers, retry, dead-letter recovery and replay without collapsing integration work into request latency.
Projection-based reads
Canonical authority remains separate from document, card, VC and proof projections so read-heavy verification can scale independently.
Portable identity and signing
OCI portability, workload identity and signer abstractions preserve the option to move to larger container, private-cloud or sovereign compute when justified.
Latent capacity is tracked rather than forgotten
Distributed verification reads, multi-core crypto workers, distributed rate limiting, batch/Merkle anchoring and independent multi-host certification remain explicitly traceable activation paths rather than silent or rediscovered capabilities.
Evidence rules
Provider capacity is not the CoreX architecture
Vercel, AWS, database, KMS, bandwidth and ledger limits are recorded as runtime constraints. Increasing those allocations can raise the measurable system ceiling without changing CoreX’s authority model.
Exact claims require reproduction
The historical 60,000–5,000,000 transactions/credentials-per-second range remains under revalidation until workload-specific evidence is reproduced and approved.