Architecture Overview

This page describes how 4Quays fits into your application architecture and how data flows through the platform.

High-Level Data Flow

When your application needs to send protected data to an external service:

1. Your Application sends plaintext payload + policy number to 4Quays (over TLS)
2. 4Quays API Gateway receives the request and routes it to the Policy Engine
3. Policy Engine resolves the correct algorithm, keys, and cryptographic packaging
4. Key Management provides the necessary key material
5. 4Quays returns the opaque protected payload to your application
6. Your Application packages the protected payload into the external service's REST API call
7. External Service receives and decrypts the payload using its private key
8. Audit Log records the operation metadata

Example: Multi-Bank Integration

Consider a payroll platform that integrates with multiple banks:

┌─────────────────────────────────────────────────────────────────┐
│                     Your Application                            │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐          │
│  │Banking Module│  │Payroll Module│  │ Tax Module   │          │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘          │
└─────────┼─────────────────┼─────────────────┼──────────────────┘
          │                 │                 │
          │ plaintext +     │ plaintext +     │ plaintext +
          │ policy number   │ policy number   │ policy number
          ▼                 ▼                 ▼
┌─────────────────────────────────────────────────────────────────┐
│                    4Quays Platform                              │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐          │
│  │ API Gateway  │──│Policy Engine │──│Key Management│          │
│  └──────────────┘  └──────────────┘  └──────────────┘          │
│                           │                                     │
│                    ┌──────┴──────┐                             │
│                    │ Audit Log   │                             │
│                    └─────────────┘                             │
└─────────────────────────────────────────────────────────────────┘
          │                 │                 │
          │ protected       │ protected       │ protected
          │ payload         │ payload         │ payload
          ▼                 ▼                 ▼
┌─────────────────────────────────────────────────────────────────┐
│                  External Services                              │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐          │
│  │   Bank A     │  │   Bank B     │  │Tax Authority │          │
│  │ AES+RSA      │  │ AES+ML-KEM   │  │  RSA Sign    │          │
│  └──────────────┘  └──────────────┘  └──────────────┘          │
└─────────────────────────────────────────────────────────────────┘

Component Responsibilities

API Gateway

• Receives all incoming requests from applications
• Authenticates requests using API keys
• Routes requests to the appropriate processing pipeline
• Returns protected payloads to applications

Policy Engine

• Looks up policies by policy number
• Resolves the cryptographic configuration for each request
• Determines algorithm, key, and packaging requirements
• Handles policy versioning and scheduled transitions

Key Management

• Stores and manages all cryptographic keys
• Handles key provisioning, rotation, and retirement
• Provides key material to the Policy Engine for operations
• Tracks key metadata and usage

Audit Log

• Records every operation with metadata
• Stores policy, algorithm, and timing information
• Never stores plaintext or ciphertext content
• Provides compliance reporting and debugging capability

What Your Application Does

Your application maintains these responsibilities:

1. Business logic: Transfer validation, data formatting, error handling
2. REST API packaging: Structuring the protected payload into the external service's expected format
3. Service communication: Sending requests to external services over TLS
4. Response handling: Processing responses from external services

What 4Quays Does

4Quays takes over these responsibilities:

1. Algorithm selection: Choosing the right encryption/signing algorithm
2. Key management: Storing, rotating, and retiring keys
3. Cryptographic operations: Encrypting, decrypting, signing, verifying
4. Compliance tracking: Logging all operations for audit purposes

Opaque Protected Payload

The protected payload returned by 4Quays is intentionally opaque:

{
  "v": 1,
  "alg": "AES-256-GCM+RSA-2048",
  "kid": "key-fingerprint",
  "ek": "base64-wrapped-key",
  "iv": "base64-nonce",
  "ct": "base64-ciphertext",
  "tag": "base64-auth-tag"
}

Your application should treat this as an opaque blob — do not parse, modify, or inspect it. Simply package it into the external service's expected format.

Separation of Concerns

4Quays creates a clear separation:

If a service changes its encryption scheme: Only the 4Q policy changes — no code changes needed.

If a service changes its REST API schema: Only the application code changes — policy stays the same.

Integration Points

4Quays integrates at two levels:

Runtime API (Your Application)

// Your application calls this
const protected = await fourq.protect(payload, 'POLICY-123');
const decrypted = await fourq.unprotect(encrypted, 'POLICY-123');

Management API (Your Security Team)

// Security team configures this
await fourq.admin.createService({ name: 'Bank A', type: 'destination' });
await fourq.admin.createPolicy({ source: 'app', destination: 'bank-a', algorithm: 'AES-256-GCM+RSA' });

What's Next

• Integration Guide — Step-by-step integration instructions
• Platform Guide — Managing services and policies
• API Reference — Detailed API documentation