Nexiv Labs is now operating six divisions across healthcare, veterinary, commerce and infrastructure. See the group →
The shared platform

One engineering spine, six businesses

Every Nexiv division inherits the same identity, payments, records, messaging and delivery infrastructure. A new product does not start at zero — it starts at production-grade.

Request path

How a request travels

Edge, gateway, services, data. Four tiers, mutually authenticated, traced end to end, with an audit event written at every state change.

Platform topology · live simulation
mTLS between tiers OpenTelemetry span per hop default-deny network policy

Edge

Global CDN, TLS termination, WAF rules, bot mitigation and DDoS absorption before traffic reaches any origin.

CDN · WAF · DNS

Gateway

Token validation, scope enforcement, per-tenant rate limits, request signing and routing to the correct regional cluster.

AuthN · AuthZ · Limits

Services

Domain services with typed contracts, idempotent commands, transactional outbox publishing and asynchronous workers for long jobs.

API · Worker · Stream

Data

Row-level-secured PostgreSQL, Redis for hot paths, object storage with per-tenant keys, and an append-only event log.

Postgres · Redis · Object
Shared services

Fourteen things nobody has to build twice

This is the actual reason the group structure works. Every item below is written once, hardened once, audited once — and consumed by all six divisions.

Identity

OIDC provider, SSO federation, MFA, session management and device trust.

Authorisation

Centralised policy decisions with per-resource, per-attribute rules.

Payments

Card, wallet and bank rails; escrow, split payouts, refunds and chargeback handling.

Billing & tax

Subscriptions, metering, invoicing, VAT determination and revenue reporting.

Records

Encrypted document and media store with retention, legal hold and export.

Events

Kafka backbone with schema registry, replay and dead-letter handling.

Notifications

Email, SMS, push and in-app with consent state and delivery receipts.

Real-time media

WebRTC signalling, SFU media routing and TURN relay for consultations.

Search

Hybrid lexical and vector retrieval with per-tenant index isolation.

Verification

Identity, licence and registration checks with re-verification scheduling.

Audit

Append-only access and change log, queryable and exportable per tenant.

Analytics

Event pipeline into a governed warehouse with lineage and metric ownership.

AI gateway

Model routing, prompt versioning, guardrails, cost caps and eval hooks.

Design system

Tokens, components and accessibility patterns shared across all products.

Specification

The layer-by-layer detail

Client tier
  • WebNext.js, TypeScript strict, server components, edge rendering for public pages
  • MobileReact Native shared core; native Swift/Kotlin modules for media and biometrics
  • OfflineLocal-first cache with conflict resolution for clinical and field workflows
  • AccessibilityWCAG 2.2 AA target; automated and manual checks in the release gate
Service tier
  • LanguagesTypeScript, Go, Python
  • ContractsOpenAPI + protobuf, generated clients, breaking-change detection in CI
  • MessagingKafka with schema registry; transactional outbox for exactly-once semantics
  • RuntimeKubernetes, workload identity, default-deny network policy, signed images
Data tier
  • Primary storePostgreSQL with row-level security and per-tenant schemas where isolation demands it
  • CacheRedis for sessions, rate limiting, idempotency keys and hot reads
  • ObjectsEncrypted object storage, per-tenant envelope keys, signed time-limited URLs
  • BackupsPoint-in-time recovery within 5 minutes; restores rehearsed quarterly
Cross-cutting
  • EncryptionTLS 1.3 in transit; AES-256 at rest; keys in managed KMS with rotation
  • TracingOpenTelemetry propagated end to end, sampled at 100% for clinical flows
  • SecretsVault-issued short-lived credentials; no static secrets in images or config
  • Supply chainSBOM per build, vulnerability gate, artefact signing verified at admission
Tenancy model

Isolation matched to sensitivity

Not every workload needs the same blast radius. We run three isolation tiers and assign each tenant deliberately rather than by default.

TierIsolationTypical use
SharedRow-level security, shared cluster and databaseMarketplace buyers, public content
Dedicated schemaOwn schema and encryption key, shared clusterPractices, seller organisations, employers
ClinicalOwn namespace, database and node pool; region-pinnedHealth and veterinary tenants
policy/admission.rego 
# Clinical workloads cannot leave their region,
# and cannot run without an owner and a data class.
deny[msg] {
  input.tier == "clinical"
  input.spec.region != input.tenant.residency
  msg := "residency violation: workload region mismatch"
}

deny[msg] {
  not input.metadata.labels["data-class"]
  msg := "every workload must declare a data class"
}

deny[msg] {
  not input.spec.image.signature.verified
  msg := "unsigned image rejected at admission"
}

Policy runs at admission, so a misconfigured deployment is refused by the cluster rather than caught in a later review. Guardrails that depend on someone remembering are not guardrails.

Want this platform behind your product?

Nexiv Technology builds on it and Nexiv Cloud runs it. Both are available to partners, not just to our own divisions.

Start a conversation Trust centre