Architecture Overview

Quantra is built as a layered, modular platform that separates concerns across distinct tiers. The browser-based frontend communicates with a Django application server, which delegates pipeline orchestration to the CNO (Central Node Orchestrator). The CNO coordinates work across a fleet of gRPC-based microservices, each responsible for a specific processing capability. All processed data flows into and out of a configurable data layer.

System Architecture Diagram

 +-------------------------------------------------------------+
 |                        BROWSER LAYER                         |
 |  HTML5 Canvas  |  JavaScript UI  |  WebSocket / Fetch API    |
 +------------------------------+------------------------------+
                                |
                          HTTPS (port 4443)
                                |
 +------------------------------v------------------------------+
 |                     DJANGO APPLICATION                      |
 |                                                              |
 |  REST API (111 routes)  |  Auth / MFA  |  Project Manager    |
 |  Plugin Registry        |  Graph Engine |  Audit Logger      |
 |  Static Files           |  Admin Views  |  User Management   |
 +------------------------------+------------------------------+
                                |
                    HTTP/NDJSON Streaming (port 8443)
                                |
 +------------------------------v------------------------------+
 |                  CNO  (Central Node Orchestrator)             |
 |                                                              |
 |  Topological Sort  |  Node Scheduler  |  Progress Streamer   |
 |  Edge Resolver     |  Error Handler   |  Result Aggregator   |
 +--------+-------------------+--------------------+-----------+
          |                   |                    |
     gRPC + mTLS         gRPC + mTLS          gRPC + mTLS
          |                   |                    |
 +--------v------+  +---------v-----+  +-----------v-----------+
 |  Datasource   |  |    Tool       |  |     Workbench         |
 |  Microservices|  |  Microservices|  |     Microservices      |
 |               |  |               |  |                       |
 |  Windows Share|  |  OCR Tool     |  |  SAR Workbench        |
 |  MSSQL       |  |  PII Tool     |  |  Review Workbench     |
 |  Snowflake   |  |  Summary Tool |  |                       |
 |  SharePoint  |  |  Hash Tool    |  |                       |
 |  Outlook     |  |  Redactor     |  |                       |
 |  Box.com     |  |  ...          |  |                       |
 +---------+-----+  +-------+------+  +-----------+-----------+
           |                |                      |
           +----------------+----------------------+
                            |
              +-------------v--------------+
              |        DATA LAYER          |
              |                            |
              |  SQLite / PostgreSQL / MSSQL|
              |  File System Storage       |
              |  Snowflake Warehouse       |
              |  External APIs             |
              +----------------------------+

Component Overview

The following table summarises every major component in the Quantra architecture, its responsibility, and where it runs.

Communication Protocols

gRPC with Protocol Buffers

All communication between the CNO and individual microservices uses gRPC, Google's high-performance remote procedure call framework. Each microservice defines its interface using Protocol Buffer (.proto) files located in the shared grpc/ directory. This approach provides several advantages:

• Strong typing — Protocol Buffers enforce a strict schema for all messages, catching integration errors at compile time rather than runtime.
• Streaming support — gRPC natively supports server-side, client-side, and bidirectional streaming, enabling microservices to send progress updates and large result sets incrementally.
• Mutual TLS (mTLS) — Every gRPC channel is secured with mutual TLS authentication. Both the client (CNO) and server (microservice) present certificates and verify each other's identity. Certificates are stored in the /ms/certs/ directory and referenced in settings.py.
• Efficient serialisation — Protocol Buffers use a compact binary format that is significantly smaller and faster to parse than JSON or XML.

HTTP/NDJSON Streaming

The Django application communicates with the CNO over HTTP using Newline-Delimited JSON (NDJSON) streaming on port 8443. When a user executes a pipeline, Django opens a streaming HTTP connection to the CNO and receives a continuous stream of progress events. Each line in the stream is a complete JSON object representing an event such as:

• Node execution started
• Node progress percentage update
• Node execution completed with results
• Node execution failed with error details
• Overall pipeline completion status

These events are forwarded to the browser in real time, allowing users to see live progress as their pipeline executes.

REST API

The Django application exposes 111 REST API routes that power all browser interactions. These routes handle project CRUD operations, user authentication, graph management, plugin queries, service endpoint administration, audit log retrieval, and more. The API follows standard REST conventions with JSON request and response bodies, and all endpoints require authentication via session cookies or tokens. Detailed route documentation is available in the API Reference appendix.

Data Flow Through Pipelines

Understanding how data moves through Quantra is essential for both users and developers. The following describes the complete lifecycle of a pipeline execution from design to result delivery.

Plugin Architecture

Quantra's functionality is extended through a plugin system. Plugins are self-contained packages that add new capabilities to the platform without modifying core code. There are three types of plugins:

Plugin Manifest (plugin.json)

Every plugin includes a plugin.json manifest file that describes the plugin to the platform. This file contains metadata such as the plugin's name, version, type, description, author, configuration schema, and the microservice endpoint it communicates with. The platform reads these manifests at startup to populate the node palette in the canvas editor.

{
    "name": "ocr_tool",
    "display_name": "OCR Tool",
    "type": "tool",
    "version": "1.4.2",
    "description": "Optical Character Recognition with multiple backend engines",
    "author": "Quantra",
    "endpoint": "ocr_service",
    "port": 50064,
    "config_schema": {
        "backend": {
            "type": "select",
            "options": ["textract", "paddleocr", "trocr"],
            "default": "paddleocr"
        },
        "language": {
            "type": "string",
            "default": "en"
        }
    }
}

Dynamic Discovery

Plugins are discovered dynamically from the /plugins/ directory at application startup. The platform scans subdirectories, reads each plugin.json manifest, validates the schema, and registers the plugin in the internal registry. This means new plugins can be added simply by placing them in the plugins directory and restarting the platform — no code changes to the core application are required.

Technology Stack