How MerxIQ
is built.
Cloud infrastructure, AI orchestration, the API layer and multi-tenant isolation — the four layers your engineering and security teams will want to review.
POST /v1/ai/insights // tenant-scoped, routed through the AI orchestration layer { "tenant": "school_482", "signal": "attendance_risk", "model": "claude" } → 200 OK
Cloud Architecture
Containerized, multi-cloud, horizontally scaled
Every service ships as a container and runs across Azure and AWS, so capacity grows with demand instead of being provisioned ahead of it.
Containerized services
Each service is packaged with Docker and orchestrated with Kubernetes, so it deploys, scales and rolls back independently.
Multi-cloud footprint
Services run across Azure and AWS rather than depending on a single provider.
Stateless, auto-scaled app tier
The application layer holds no session state, so Kubernetes can add or remove instances horizontally as traffic changes.
Data and caching tier
PostgreSQL is the system of record; Redis caching absorbs read-heavy traffic before it reaches the database.
Request Flow
How a request moves through MerxIQ
From a browser to a tenant-scoped response, every layer runs independently scalable and independently secured.
AI Architecture
A multi-model orchestration layer
Product features never call a model provider directly. Every AI request goes through one orchestration layer that handles routing, tenant scope and logging.
Multi-model routing
The orchestration layer routes each request to the model best suited to the task, across providers.
Tenant-scoped by default
Every AI request carries its tenant, so a school’s data is only ever used to answer that school’s questions.
Asynchronous workloads
AI work runs asynchronously, so a slow model call never blocks the request path for anyone else.
Traceable AI actions
AI-assisted actions are audit-logged alongside admin actions, so every suggestion can be traced back to who triggered it.
API Layer
One API, guarded at every request
The Laravel API sits between every client and every data store. Each call is authenticated, authorized and scoped to a tenant before it touches data.
- Versioned REST endpoints, such as
/v1/ai/insights - Role-based access control enforced on every endpoint and admin action
- Every request resolved to a tenant before any query runs
- TLS on every connection; responses served from Redis cache where possible
- Authentication, authorization and data-access events audit-logged
GET /v1/attendance/summary // 1. authenticate → session + password policy // 2. authorize → role: principal // 3. scope → tenant: school_482 // 4. read → redis, then postgres // 5. audit → event logged → 200 OK
Multi-Tenant Design
One platform. Every school isolated.
MerxIQ runs as a single shared platform across schools, with strict logical isolation at every layer — so one tenant's data, load, or incident never touches another's.
- Every row is scoped to a tenant ID, enforced at the database layer — not just in application code
- Each tenant gets its own Redis namespace for sessions and cache, so one school's traffic can't evict another's
- Shared compute, isolated blast radius — a problem in one tenant's workload doesn't degrade another's
PostgreSQL
Redis
Postgres + logs
Reviewing MerxIQ for your organization?
We’ll walk your engineering and security teams through each layer. Talk to engineering