RestartiX Platform

Appearance

System Overview ​

For developers

This section covers the technical architecture of the platform. If you're looking for a non-technical overview, see the Platform Overview.

RestartiX Platform is a single Go binary backed by a PostgreSQL database. Simple to deploy, simple to reason about — but built on principles that make it secure, compliant, and scalable from day one.

The big picture ​

  Patients ──────────► Patient Portal ──────┐
                       (web interface)       │
                                             │    ┌─────────────────────────┐
                                             ├───►│   RestartiX Platform        │───► PostgreSQL
  Specialists                                │    │   (Go API, port 9000)   │     (clinic data,
  Admins ────────────► Clinic App ───────────┘    │                         │      RLS isolated
  Platform owners      (web interface)            │  ├── Auth & Users       │      per clinic)
                                                  │  ├── Scheduling         │
                                                  │  ├── Patient Profiles   │───► Redis
                                                  │  ├── Forms & Documents  │     (sessions,
                                                  │  ├── Treatment Plans    │      rate limiting,
                                                  │  ├── Automations        │      booking holds)
                                                  │  └── Webhooks & Audit   │
                                                  └──────────┬──────────────┘
                                                             │
                                                             ▼
                                                  ┌─────────────────────────┐
                                                  │  Telemetry API          │───► ClickHouse
                                                  │  (port 4000)            │     (analytics data)
                                                  │  analytics, audit,      │
                                                  │  video tracking         │
                                                  └─────────────────────────┘

Two services, one codebase (monorepo). The Core API handles everything clinics need day-to-day. Telemetry handles high-frequency analytics, detailed audit enrichment, and video session tracking — kept separate because it operates at a different scale and rhythm than clinical operations.

Curated platform model. Clinics do not self-register. A platform operator (superadmin) creates and configures each organization, assigns the initial admin, and sets up the clinic's subdomain. This ensures compliance vetting, proper configuration, and quality control before a clinic goes live. The superadmin role has cross-organization access and bypasses all RLS policies — it is reserved for the platform team, not for clinic staff.

How clinic data stays isolated ​

Every piece of data in the system belongs to an organization (clinic). When a specialist at Clinic A logs in, every database query they trigger is automatically filtered to Clinic A's data only — enforced by the database itself, not just application code.

This is called Row-Level Security (RLS). It means:

  • A bug in application code cannot accidentally expose Clinic B's data to Clinic A
  • There is no "super-query" that bypasses this — even the application developers can't accidentally cross clinic boundaries
  • Auditors can verify this behavior directly at the database level
              ┌──────────────────────────────┐
              │    Patient profiles          │
              │    (portable, patient-owned)  │
              │                              │
              │  Shared only with explicit   │
              │  per-clinic consent          │
              └──────────────┬───────────────┘
                             │
              ┌──────────────┼───────────────┐
              ▼              ▼               ▼
     ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
     │   Clinic A   │ │   Clinic B   │ │   Clinic C   │
     │              │ │              │ │              │
     │ Appointments │ │ Appointments │ │ Appointments │
     │ Forms & docs │ │ Forms & docs │ │ Forms & docs │
     │ Treatments   │ │ Treatments   │ │ Treatments   │
     │ Segments     │ │ Segments     │ │ Segments     │
     │ Automations  │ │ Automations  │ │ Automations  │
     │ Audit trail  │ │ Audit trail  │ │ Audit trail  │
     └──────────────┘ └──────────────┘ └──────────────┘
      DB-level isolation  DB-level isolation  DB-level isolation

How requests work ​

Every request goes through the same chain. Organization context is request-scoped, determined by the domain the user is visiting:

  Browser hits healthcorp.clinic.restartix.app (or clinic.myclinic.com)
                          │
                          ▼
  ┌─────────────────────────────────────────────┐
  │  Next.js Proxy (proxy.ts)                   │
  │                                             │
  │  1. Extract slug from subdomain             │
  │     OR detect custom domain                 │
  │  2. Call Core API public resolve endpoint   │
  │     GET /v1/public/organizations/resolve    │
  │     ?slug=healthcorp  OR  ?domain=...       │
  │  3. Set org-id, org-slug cookies            │
  │  4. Enforce Clerk auth for protected routes │
  └──────────────────┬──────────────────────────┘
                     │ (org-id cookie → X-Organization-ID header)
                     ▼
  ┌─────────────────────────────────────────────┐
  │  Core API (Go)                              │
  │                                             │
  │  5. Clerk Auth Middleware                   │
  │     validates JWT (or rejects with 401)     │
  │  6. Organization Context Middleware         │
  │     reads X-Organization-ID header,         │
  │     validates membership, sets RLS vars:    │
  │     app.current_org_id, app.current_role    │
  │  7. Handler — executes the operation        │
  │  8. Audit log — records what happened       │
  └─────────────────────────────────────────────┘

Key: The frontend proxy resolves the org from the domain (with Redis caching), then every API call includes the X-Organization-ID header. The Core API validates membership and sets database-level isolation via RLS. No step can be skipped — there's no way to reach a handler without passing through auth and organization context.

Tech stack at a glance ​

LayerTechnologyWhy
LanguageGo 1.24+Fast, compiled, small binaries, excellent concurrency
HTTP RouterchiLightweight, stdlib-compatible
DatabasePostgreSQL 17+Row-Level Security, reliable, battle-tested
AuthClerkSOC 2 Type II, HIPAA BAA available, handles MFA and social login
File StorageAWS S3Industry standard for medical-grade file storage
Video CallsDaily.coHIPAA-compliant video rooms with API
Session CachingRedisBooking holds, rate limiting, webhook idempotency
Analytics DBClickHouseColumnar, optimized for time-series and analytics

Core design principles ​

1. Multi-tenant by default Every table has an organization_id. Every query is organization-scoped via RLS. No exceptions.

2. Clerk for auth, own database for tenancy Clerk handles login, MFA, password reset, and sessions. The platform's own organizations table is the source of truth for which clinic a user belongs to. These are separate concerns handled by the right tool.

3. Explicit over magic No auto-generated routes, no ORM magic. Every endpoint, every query, every middleware is hand-written and visible in the codebase.

4. Fail closed Missing auth → 401. Missing org context → 403. Invalid input → 400. No silent defaults. The system rejects before it guesses.

5. Audit everything Every data mutation produces an audit log entry, written synchronously. Nothing can change without a record of it.

For developers ​