Skip to main content

​
High-Level Architecture

TLQ FHIR architecture diagram Conceptual view
  • Stateless API nodes handle FHIR requests
  • Background workers process asynchronous and long-running tasks
  • PostgreSQL acts as the single system of record
  • An Admin UI provides operational visibility

​
Runtime Components

​
API Server

The API server exposes the FHIR REST interface.
  • Handles validation, authorization, and request processing
  • Implements CRUD, search, batch, transaction, and operation endpoints
  • Stateless and horizontally scalable

​
Background Workers

Background workers execute work that should not block HTTP requests.
  • Search indexing
  • Terminology expansion
  • Bulk and long-running operations
  • Package installation and maintenance
Workers can be scaled independently from the API.

​
Database

PostgreSQL is the only persistent datastore. It stores:
  • FHIR resources and full version history
  • Search indexes
  • Background jobs
  • Installed FHIR packages and metadata
This design avoids hidden state and simplifies backup and recovery.

​
Admin UI

A web-based interface for operators and administrators.
  • Browse and inspect resources
  • Monitor background jobs
  • Inspect indexing and terminology status
  • Troubleshoot server behavior

​
Example Request Flow

Posting a transaction
  1. A client sends a FHIR Transaction bundle to the API
  2. The server validates the bundle and applies FHIR transaction rules
  3. The resources are stored in a database transaction
  4. Indexing work gets queued for background processing
  5. The client gets an immediate response