Tenant Isolation (Iron Dome)

Quasar operates as a multi-tenant SaaS backend. A core tenet of the TUWA architecture is strict Tenant Isolation. Data leakage between different users or applications is treated as a critical, non-negotiable failure.

The organizationId Boundary

Every query executed within Quasar is strictly scoped by an organizationId. Whether the SDK is pushing a new transaction or fetching history, the underlying database schemas—powered by Drizzle ORM—enforce this boundary.

When you send a request with your Secret Key, the Quasar Engine first resolves that key to its parent Organization. From that moment, every database transaction is bound to that Organization’s partition. Cross-tenant data access is structurally impossible.

The Iron Dome Architecture

To achieve high performance without compromising security, Quasar is split into a dual-subdomain architecture known as “The Iron Dome”.

Management Layer (quasar.tuwa.io)

• Purpose: Dashboard UI, Payload Admin, Client Auth, and App configuration.
• Tech: Next.js App Router (Stateless).
• Security: Relies on Payload Auth, WebAuthn, and standard cookie-based sessions.

Performance Layer (api.tuwa.io)

• Purpose: High-performance Engine API for the Quasar SDK (/v1/engine/*).
• Tech: NestJS & Fastify (Stateless, horizontally scaled).
• Security: Protected by the IronDomeGuard. This guard intercepts every SDK request, performs SHA-256 resolution on the sk_live_... headers, enforces strict RPS (Requests Per Second) limits, and applies Smart Degradation logic if quotas are exceeded.

By physically separating the management APIs from the ingestion APIs, Quasar ensures that heavy traffic loads (like thousands of blockchain transactions syncing simultaneously via Pulsar) never degrade the dashboard experience or compromise the management security vectors.