Platform · Performance & low latency
Speed is designed in, with a budget for every interaction
One3 sets explicit latency targets for every kind of interaction, for people and agents alike, and tests them in CI. Every number on this page is a design target, not a measured result.
How to read the numbers on this page
Every figure here is a design target from the One3 plan. None is a measured result. Targets are replaced by measured values from the planned benchmark and load-test sprints. One3's own claim rules forbid "ultra-low latency" claims without measured p95 evidence.
Eight performance principles
These rules shape every part of the platform.
Budgets before code
Every interaction class has p50/p95/p99 targets split across hops. A feature that cannot meet its budget becomes async instead of breaking it.
One or two database trips
Auth, entitlement and permission checks come from local verification and caches, not network calls per row.
Tenant-first design
Every hot index leads with the tenant. Every cache key contains the tenant. Nothing is cached across tenants.
Durable writes, async follow-ups
A write commits its row and outbox event in one transaction. Search, read models, notifications and AI enrichment follow after commit.
Stream anything slow
The app shell streams, AI streams tokens, and long jobs stream progress.
Interactive never waits for batch
Separate pools, queues and priority lanes exist from day one.
A complexity budget
Postgres, Valkey, NATS and Temporal carry W0–W2. ClickHouse, OpenSearch and Qdrant enter at W3+ only when measured signposts fire.
Explicit, measured claims
"Low latency" means named targets with evidence, never a vague promise.
Latency budgets per interaction class (design targets)
| Interaction class | p50 | p95 | p99 |
|---|---|---|---|
| Page shell, time to first byte | 120 ms | 300 ms | 600 ms |
| List or board view, first page | 60 ms | 180 ms | 400 ms |
| Record detail | 50 ms | 150 ms | 350 ms |
| Low-risk Action write (R0/R1) | 70 ms | 200 ms | 450 ms |
| Global search | 120 ms | 350 ms | 800 ms |
| Typeahead, per keystroke | 40 ms | 100 ms | 250 ms |
| Permission / entitlement check, cache hit | < 1 ms | 3 ms | 10 ms |
| Realtime message fan-out | 80 ms | 250 ms | 600 ms |
| Dashboard tile | 150 ms | 600 ms | 1.5 s |
| Copilot first token | 700 ms | 1.5 s | 3 s |
| RAG answer, complete | 3 s | 6 s | 10 s |
| Agent step, excluding external APIs | 1.5 s | 4 s | 8 s |
| Voice agent turn | 900 ms | 1.5 s | 2.5 s |
Every endpoint declares its class
Each Action, view and API endpoint declares a latency class in its manifest: interactive read, interactive write, search, typeahead, AI stream, agent or batch. CI performance tests then hold it to that class's budget.
Some work is async by design. An R3 Action that needs approval is accepted quickly and returns pending approval; completion happens on human time. Bulk imports through the Migration Factory and large report exports run as background jobs with progress events, never on the interactive pool.
An honest note on voice. Sub-second voice turns need every stage to stream: speech recognition, the model's first token and text-to-speech. Hosted model latency varies by provider, region and load, and Indian-language speech models may trade speed for quality. Some turns will exceed the budget, for example when a tool call is needed.
Caching layers
| Layer | What is cached | How it stays correct |
|---|---|---|
| Browser | Hashed static assets | Content hash in the file name |
| CDN | Static assets and public, non-personal pages | Purged on deploy or publish; never authenticated API responses |
| App data cache | Tenant-level, non-personal config such as branding and navigation | Tag-based revalidation on config events |
| Identity & access cache | Entitlements, permission scopes, session revocation list | Versioned keys bumped on subscription or role changes |
| Config cache | Object and field definitions, views, workflows, Constitution | Invalidated on publish |
| Query result cache | Only expensive dashboard tiles and report aggregates | Keyed by tenant, query, permission scope and data version |
| AI semantic cache | Answers to repeated questions over unchanged knowledge | Keyed by tenant, collection version and access scope; never across tenants |
Cache key rules
Every key starts with the tenant ID, and a key without it fails a lint check. User-visible data keys include a permission-scope hash, so two users with different access never share an entry. Versioned keys are preferred over deletes. There are no cross-tenant caches, not even "popular answers"; shared caches hold only truly public data such as currency rates.
Realtime and async work
Durable truth lives in Postgres. Realtime is a notification layer that clients can always recover from.
WebSocket gateway
A dedicated, stateless gateway authenticates on connect and checks each channel subscription against the permission cache.
Fan-out through NATS
Interest-based subjects per cell, tenant, app and channel. Presence updates are batched; typing indicators are dropped first under load.
Ordering and recovery
Per-channel sequence numbers let clients reorder and fetch gaps. Slow consumers get a resync signal instead of silent loss.
Outbox relay
Commit-to-publish lag targets p95 ≤ 100 ms, with alerts when lag grows.
Priority lanes
Separate Temporal lanes for interactive agents, realtime automations, background agents, imports and exports, scheduled jobs and AI batch.
Streaming AI
Latency-class routing, small-model-first cascades, prefix caching, parallel tool calls, pre-computed context and fallbacks on timeout.
Multi-tenant fairness
| Control | Mechanism |
|---|---|
| API rate limits | Token buckets per tenant, user, API key and agent identity |
| Action throughput caps | Per tenant per Action family, such as bulk updates or outbound messages |
| Query cost guards | Unindexed filters rejected on large tables; statement timeouts per class; reports run on replicas |
| Job quotas | Maximum concurrent workflows per tenant per lane; agent squads capped by plan and budget |
| AI quotas | Tokens per minute and cost per day per tenant and per agent, with a hard stop |
| Realtime limits | Maximum connections per tenant and messages per second per connection |
| Noisy-neighbour detection | Per-tenant share of DB time, CPU, queues and GPU; heavy tenants are throttled or moved to a bridge or silo tier |
Built for Indian mobile networks
Frontend targets follow Core Web Vitals "good" thresholds at p75: LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1.
Per-app code splitting
Each app loads its own bundle. Bundles for apps a tenant has not subscribed to are never downloaded.
Optimistic Actions
Changes apply instantly with a pending marker and roll back with an explanation if policy or validation says no.
Lite mode
Turns on automatically on Save-Data or slow connections: no video autoplay, fewer images, smaller pages, text-first dashboards.
PWA offline reads
Recently viewed records and the approvals inbox stay readable offline. Queued Actions replay safely on reconnect.
WhatsApp-first flows
Approvals and alerts are also designed to work over WhatsApp as a light-bandwidth option.
How the targets stay true
Performance is enforced by gates, not hope.
- 1
Hot-query EXPLAIN gate
Every PR touching queries runs EXPLAIN on registered hot queries with row-level security on. No sequential scans on large tables.
- 2
Nightly endpoint budgets
k6 scenarios per latency class must meet p95 targets on a synthetic medium dataset.
- 3
Load tests
Weekly and before release, at modelled peak × 1.5, with p95/p99 within budget and no saturation above 70%.
- 4
Frontend budgets
Lighthouse CI on every PR against a Slow 4G profile, plus weekly field-data review.
- 5
Release regression gate
No hot endpoint p95 may regress more than 10% against the last release without an approved exception.
- 6
Error budgets
Burning an app's latency error budget freezes feature releases for that app until it is fixed.
Performance in plan numbers
- interaction classes with latency budgets
- 16
- performance principles
- 8
- release gates
- 6
- forbidden anti-patterns enforced in review and CI
- 20
Questions about performance
Are these latency numbers measured?
No. They are design targets from the plan. They will be replaced by measured values from benchmark and load-test sprints, and One3 will not make speed claims without measured p95 evidence.
Will another tenant's heavy usage slow us down?
The design includes per-tenant limits on API calls, Actions, jobs, AI and realtime, plus noisy-neighbour detection. Heavy tenants can be throttled or moved to a bridge or silo isolation tier.
Do AI features slow down normal screens?
They should not. Synchronous external or AI calls inside normal read requests are a forbidden anti-pattern. AI work streams, runs in its own lanes, and never shares interactive model endpoints with batch jobs.
Will One3 work on slow mobile connections?
That is a design goal. Lite mode, offline reads through a PWA, small bundles per app and WhatsApp-first flows are planned for low-bandwidth use, and frontends are tested on Slow 4G and 3G-like profiles.
Is caching safe for sensitive data?
Cache keys always include the tenant and, for user-visible data, a permission scope. Nothing is cached across tenants, and authenticated API responses are never cached at the CDN.
Talk to us about performance at your scale
Share your volumes and workflows, and we will walk you through how One3 plans to keep them fast and fair.