The Trinity Beast – System Architecture Guide

Technical overview of architecture, components, data flows, and AWS infrastructure

Region: us-east-2 (Ohio) Version: v15 Updated: April 2026

1. Overview

The Trinity Beast is a high-performance cryptocurrency price API infrastructure built on AWS, delivering real-time prices at 0ms cached response and 746,374 combined RPS capacity across TCP and UDP.

TCP Peak (Direct)
369,600 req/sec
UDP Peak (Direct)
487,900 req/sec
Combined Sustained
746,374 RPS
Cached Response
<2ms
Uncached Response
30–80ms
Cache Hit Rate
99%+
Architecture
Serverless
Availability
Multi-AZ

2. System Architecture

The system consists of three independently deployed ECS Fargate services behind an Application Load Balancer (TCP) and Network Load Balancer (UDP), backed by Aurora Serverless v2 and ElastiCache (Valkey 7.2). All containers run on the AWS Nitro System — dedicated Nitro Cards offload all networking and storage I/O to purpose-built hardware, delivering bare-metal-equivalent performance to each container. All four services maintain 6 real-time WebSocket connections to Coinbase, Gemini, Kraken, Gate.io, Crypto.com, and OKX — prices are pushed into a local sync.Map for zero-network-hop reads. The 4th service (BeastWebhook) runs the Webhook Push delivery engine, pushing prices outbound to Associates via UDP and HTTPS.

Diagram 2.1 — High-Level Architecture
graph TB
    subgraph Internet["Internet"]
        Client["Client Requests"]
    end

    subgraph LB["Load Balancers"]
        ALB["ALB v3
TCP 80/443 → 8080/9090"] NLB["NLB
UDP 2679/2680"] end subgraph ECS["ECS Fargate Cluster — 4 Services"] Main["BeastMain (AZ 2a)
APP_REPORT_SERVER
8 vCPU / 32 GB"] Mirror["BeastMirror (AZ 2b)
APP_REPORT_SERVER
8 vCPU / 32 GB"] LRS["BeastLRS (AZ 2c)
APP_REPORT_SERVER
8 vCPU / 32 GB"] Webhook["BeastWebhook
WEBHOOK_SERVER
8 vCPU / 32 GB"] Sync["Sync Job
Nightly 1 AM EST"] end subgraph Associates["Webhook Associates"] Assoc["Associate Endpoints
UDP + HTTPS"] end subgraph Data["Data Stores"] Cache["ElastiCache
Valkey 7.2
cache.r7g.2xlarge · 52 GB"] Aurora["Aurora PostgreSQL
Serverless v2
2–18 ACU"] end subgraph Feeds["6 Real-Time WebSocket Feeds"] CB["Coinbase"] GM["Gemini"] KR["Kraken"] GT["Gate.io"] BY["Crypto.com"] OK["OKX"] end subgraph AutoOps["Autonomous Operations"] EB["EventBridge"] SFN["Step Functions"] OpsLambda["5 AutoOps Lambdas"] Bedrock["Bedrock (Claude)"] end Client --> ALB Client --> NLB ALB -->|"TCP 8080 LPO"| Main ALB -->|"TCP 8080 LPO"| Mirror ALB -->|"TCP 9090 LRS"| Main ALB -->|"TCP 9090 LRS"| Mirror ALB -->|"TCP 9090 LRS"| LRS NLB -->|"UDP 2679 LPO"| Main NLB -->|"UDP 2679 LPO"| Mirror NLB -->|"UDP 2680 LRS"| Main NLB -->|"UDP 2680 LRS"| Mirror NLB -->|"UDP 2680 LRS"| LRS Main --> Cache Mirror --> Cache LRS --> Cache Webhook --> Cache Webhook --> Aurora Webhook -->|"Push Prices"| Assoc Sync --> Aurora Sync --> Cache CB -.->|"WS Push"| Main CB -.->|"WS Push"| Mirror CB -.->|"WS Push"| LRS CB -.->|"WS Push"| Webhook GM -.->|"WS Push"| Main GM -.->|"WS Push"| Mirror GM -.->|"WS Push"| LRS GM -.->|"WS Push"| Webhook KR -.->|"WS Push"| Main KR -.->|"WS Push"| Mirror KR -.->|"WS Push"| LRS KR -.->|"WS Push"| Webhook GT -.->|"WS Push"| Main GT -.->|"WS Push"| Mirror GT -.->|"WS Push"| LRS GT -.->|"WS Push"| Webhook BY -.->|"WS Push"| Main BY -.->|"WS Push"| Mirror BY -.->|"WS Push"| LRS BY -.->|"WS Push"| Webhook OK -.->|"WS Push"| Main OK -.->|"WS Push"| Mirror OK -.->|"WS Push"| LRS OK -.->|"WS Push"| Webhook EB -.->|"Monitor"| ECS EB --> SFN SFN --> OpsLambda OpsLambda -->|"Self-heal"| ECS OpsLambda --> Bedrock %% Styling — use classDef instead of fragile linkStyle indices style Internet fill:#1e293b,stroke:#334155,color:#e2e8f0 style LB fill:#1e293b,stroke:#FF9900,color:#e2e8f0 style ECS fill:#1e293b,stroke:#60a5fa,color:#e2e8f0 style Data fill:#1e293b,stroke:#10b981,color:#e2e8f0 style Feeds fill:#1e293b,stroke:#a78bfa,color:#e2e8f0 style Associates fill:#1e293b,stroke:#2dd4bf,color:#e2e8f0 style AutoOps fill:#1e293b,stroke:#f59e0b,color:#e2e8f0 style Webhook fill:#2dd4bf,stroke:#1e293b,color:#fff

3. Components

3.1 LPO Server (Listener Price Oracle)

trinity-beast-lpo-server Go / ECS Fargate

The LPO is the primary price-serving component. It checks the in-process sync.Map first (zero-network cache hit), then ElastiCache (sub-millisecond), then falls back to live exchange APIs. Real-time WebSocket feeds from 6 exchanges — Coinbase, Gemini, Kraken, Gate.io, Crypto.com, and OKX — push 150 prewarmed asset prices directly into the sync.Map with sub-second freshness.

Key Features

  • WebSocket-fed price cache: 6 persistent feeds (Coinbase, Gemini, Kraken, Gate.io, Crypto.com, OKX) — 150 prewarmed assets, REST fallback per exchange if WS stale
  • Response-first architecture: logs and metrics written in background goroutines
  • Go runtime tuned: GOMAXPROCS(NumCPU()), GCPercent(200)
  • HTTP client reuse with connection pooling
  • TCP and UDP protocols on all 6 ports (4 production + 2 dedicated health)
CPU
8 vCPU
Memory
32 GB
Ports
8080, 9090, 2679, 2680

3.2 LRS Server (Listener Report Service)

Listener Report Service Go / ECS Fargate

The LRS reads usage logs from ElastiCache and generates reports. Runs as part of the unified server in APP_REPORT_SERVER mode. Supports filtering, pagination, and multiple output formats.

Output Formats

  • json — Default, structured API response
  • csv — Comma-separated, Excel/Sheets compatible
  • tsv — Tab-delimited, database/ETL friendly
  • text — Human-readable plain text
CPU
8 vCPU
Memory
32 GB
Ports
9090, 2680

3.3 Sync Job

trinity-beast-sync-job Go / ECS Scheduled Task

Nightly scheduled task that synchronizes data from Aurora PostgreSQL to ElastiCache, keeping the LRS reporting cache current. Triggered by EventBridge at 1 AM EST (6 AM UTC).

  • Syncs usage logs from Aurora → ElastiCache (incremental, high-water mark tracking)
  • Refreshes API keys in ElastiCache (apikey:* hashes, 24h TTL)
  • Refreshes application parameters in ElastiCache (app:config hash)
  • Syncs report_usage_logs from Aurora → ElastiCache
  • Batch processing (1,000 rows/batch) with Redis pipelining
  • First run: 5–10 minutes (full history). Daily runs: 30–60 seconds (incremental)

4. Data Flows

Price Request Flow (LPO)

1
Client sends GET /price?asset=BTC with Bearer token to ALB
2
ALB routes to LPO Fargate task
3
LPO reads local sync.Map (in-process, zero-network)
4a
sync.Map hit (99%+): Returns price immediately (~0ms network). Logs usage via SQS fire-and-forget.
4b
sync.Map miss: Checks ElastiCache (<1ms). If still miss, fetches from exchange REST API (30–50ms). Writes through to ElastiCache and sync.Map.

Report Request Flow (LRS)

1
Client sends GET /reports/usage?format=csv with Bearer token
2
LRS queries ElastiCache sorted sets by time range and filters
3
Fetches full log hashes from ElastiCache
4
Formats and streams response in requested format (JSON/CSV/TSV/text)

5. AWS Infrastructure

Amazon ElastiCache (Valkey 7.2)

ElastiCache Clustercache.r7g.2xlarge
Node Type
cache.r7g.2xlarge
Memory
52.8 GB
Throughput
400K+ ops/sec

Amazon Aurora Serverless v2

Aurora PostgreSQLServerless v2
ACU Range
2–18 ACU
IOPS
Unlimited
Mode
Optimized I/O
Scaling
Auto (2–18 ACU)

Amazon ECS on AWS Fargate

All Fargate tasks run on AWS Nitro System hosts. Nitro Cards handle network packet processing, EBS I/O, and instance management in dedicated hardware — freeing 100% of the 8 vCPUs per container for application workload. This hardware-level offloading is a key factor in achieving 746,374 sustained RPS across TCP and UDP.

ServiceCPUMemoryTasksScaling
BeastMain (APP_REPORT_SERVER)8 vCPU32 GB1Horizontal (add tasks)
BeastMirror (APP_REPORT_SERVER)8 vCPU32 GB1Horizontal (add tasks)
BeastLRS (APP_REPORT_SERVER)8 vCPU32 GB1Horizontal (add tasks)
BeastWebhook (WEBHOOK_SERVER)8 vCPU32 GB1Outbound push — no ALB
Sync Job0.5 vCPU1 GB1Nightly scheduled

6. Deployment Strategies

Strategy 1: Separate Services (Production)

Each component runs as an independent ECS service. Allows independent scaling and zero-downtime deployments.

✅ Recommended for production. Currently deployed configuration.

Strategy 2: Combined Service (Development)

LPO and LRS run in a single container using APP_REPORT_SERVER mode. Simpler deployment, good for dev/staging environments.

Strategy 3: Hybrid (Flexible Scaling)

LPO scales horizontally (multiple tasks) while LRS remains single-task. Use when LPO traffic increases but reporting load stays low.

Traffic LevelTasksModeCapacity
Production (current)4 (3 LPO/LRS + 1 Webhook)APP_REPORT_SERVER + WEBHOOK_SERVER369,600 TCP req/sec (direct)
Scaled (6 LPO tasks)7APP_REPORT_SERVER + WEBHOOK_SERVER~739,200 TCP req/sec (direct)
Scaled (9 LPO tasks)10APP_REPORT_SERVER + WEBHOOK_SERVER746,374 combined RPS (proven Run 17)

7. Networking & Endpoints

Public Endpoints

ServiceProtocolEndpointPortLoad Balancer
LPO (Price API)HTTPSapi.cpmp-site.org443ALB (Trinity-Beast-TCP-ALB)
LRS (Reports)HTTPSlrs.cpmp-site.org443ALB (Trinity-Beast-TCP-ALB)
LPO (UDP)UDPudp.cpmp-site.org2679NLB (Trinity-Beast-UDP-NLB)
LRS (UDP)UDPudp.cpmp-site.org2680NLB (Trinity-Beast-UDP-NLB)

PrivateLink (VPC-to-VPC)

PrivateLink NLBTCP

Enterprise subscribers access both LPO (TCP 8080) and LRS (TCP 9090) via AWS PrivateLink through a dedicated NLB. No public internet traversal — traffic stays within the AWS backbone.

LPO Port
TCP 8080
LRS Port
TCP 9090
NLB
Trinity-Beast-NLB

VPC Architecture

VPC PeeringActive

The Trinity VPC (vpc-03deaddb7083cd59c) is peered with the default VPC (vpc-0876ee7be3a677f26) for Aurora Serverless v2 connectivity. Route tables in both VPCs have cross-VPC routes configured.

VPC Endpoints (Interface)

ServicePurpose
com.amazonaws.us-east-2.ssmSystems Manager for ECS Exec
com.amazonaws.us-east-2.ssmmessagesSSM session channels
com.amazonaws.us-east-2.ecsECS API access
com.amazonaws.us-east-2.ecr.apiECR image pulls
com.amazonaws.us-east-2.ecr.dkrECR Docker registry
com.amazonaws.us-east-2.logsCloudWatch Logs
com.amazonaws.us-east-2.monitoringCloudWatch Metrics
com.amazonaws.us-east-2.elasticacheElastiCache access
com.amazonaws.us-east-2.rdsAurora RDS access
com.amazonaws.us-east-2.s3S3 access (Gateway)
com.amazonaws.us-east-2.cloudtrailCloudTrail events

AI & Translation Services

ServicePurposeIntegration
Amazon TranslateReal-time bi-directional translation for all support correspondenceECS containers call Translate API via IAM task role
Amazon SESMulti-lingual transactional email (support confirmations, replies, newsletter welcome)ECS containers + Lambda (receipt processor)

Language is not a barrier. The website serves 12 languages via static JSON. Dynamic correspondence (support tickets, email replies) is translated in real-time by AWS Translate. Customers write in their language, admin reads in English. Admin replies in English, customers receive in their language. Both versions stored for audit. Cost: < $1/month at current volume.

8. Operations & Monitoring

CloudWatch Dashboards

DashboardContents
Trinity-Beast-Application-DashboardLPO/LRS app metrics, ECS CPU/memory, ALB latency, ElastiCache, Aurora ACU, container logs, CloudTrail events, VPC flow logs
Trinity-Beast-Master-DashboardInfrastructure overview

Custom CloudWatch Metrics

NamespaceKey Metrics
TrinityBeast/LPORequests, CacheHitRate, AvgLatencyMs, ErrorCount, SourceFailover, RequestsByAsset, RequestsBySource
TrinityBeast/LRSReportRequests, UsageRequests, SummaryRequests, AvgLatencyMs, FormatJSON/CSV/TSV/Text

Nightly Sync Job

Aurora → ElastiCache SyncEventBridge

Runs nightly at 1 AM EST via EventBridge. Syncs usage logs from Aurora to ElastiCache for LRS reporting. Full historical load completes in ~16 seconds; incremental syncs under 200ms.

Security & Auditing

ECS Exec & Database Access

ℹ️ Port Forwarding to Aurora: Use the container runtime ID (not container name) for SSM port forwarding:
aws ssm start-session \
  --target ecs:<cluster>_<taskId>_<runtimeId> \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"host":["aurora-endpoint"],"portNumber":["5432"],"localPortNumber":["5432"]}' \
  --region us-east-2

Get the runtime ID: aws ecs describe-tasks --tasks <taskId> --query 'tasks[0].containers[0].runtimeId'

9. Autonomous Operations (AutoOps)

A 5-layer intelligent operations system that monitors, defends, heals, and reports on the TBI infrastructure autonomously. Self-heal first, notify second.

Diagram 9.1 — AutoOps Event Flow
graph LR
    subgraph Sources["Event Sources"]
        CW["CloudWatch Alarms"]
        HP["Honeypot Hits"]
        GD["GuardDuty"]
        WAF["WAF Blocks"]
    end

    subgraph EventBus["EventBridge"]
        EB["Event Bus"]
        R1["tbi-ops-alarm-trigger"]
        R2["tbi-ops-honeypot-queue
(every 5 min)"] end subgraph Orchestration["Step Functions"] SF["tbi-ops-health-check-heal"] end subgraph Actions["Lambda Actions"] SH["tbi-ops-self-heal
ECS restart/deploy"] WA["tbi-ops-waf-action
IP block/unblock"] NT["tbi-ops-notify
SNS alerts"] HPP["tbi-ops-honeypot-processor
Queue drain"] BA["tbi-ops-bedrock-analyze
AI threat analysis"] BS["tbi-raima-support
Raima Support Assistant"] DG["tbi-ops-digest
Daily/weekly reports"] end subgraph AI["Amazon Bedrock"] Claude["Claude Sonnet 4.6
Pattern correlation"] end CW --> EB HP --> EB GD --> EB WAF --> EB EB --> R1 EB --> R2 R1 --> SF R2 --> HPP SF --> SH SF --> NT HPP --> WA HPP --> NT BA --> Claude BS --> Claude DG --> Claude Claude -->|"Advisory"| BA BA --> NT DG --> NT style Sources fill:#1e293b,stroke:#ef4444,color:#e2e8f0 style EventBus fill:#1e293b,stroke:#FF9900,color:#e2e8f0 style Orchestration fill:#1e293b,stroke:#60a5fa,color:#e2e8f0 style Actions fill:#1e293b,stroke:#10b981,color:#e2e8f0 style AI fill:#1e293b,stroke:#a78bfa,color:#e2e8f0

Event-Driven Architecture

Flow: CloudWatch Alarms / GuardDuty / WAF / Honeypot → EventBridge → Step Functions → Lambda Actions (self-heal, WAF block, notify, escalate)

AI Layer: Amazon Bedrock (Claude Sonnet 4.6) correlates threat signals every 5 minutes. Advisory only — AI suggests, Step Functions decide, Lambda acts.

Components

ComponentTypePurpose
tbi-ops-notifyLambda (Go)SNS notifications with severity levels
tbi-ops-self-healLambda (Go)ECS task restart, force-deploy, health checks
tbi-ops-waf-actionLambda (Go)WAF IP set management (block/unblock)
tbi-ops-honeypot-processorLambda (Go)Drain honeypot queue → WAF block → notify
tbi-ops-bedrock-analyzeLambda (Go)AI threat analysis via Bedrock
tbi-raima-supportLambda (Go)Raima Support Assistant — AI ticket categorization + draft responses (Claude Opus 4)
tbi-ops-digestLambda (Go)Daily/weekly operational digests via Bedrock
tbi-ops-health-check-healStep FunctionOrchestrate health check → heal → verify → notify
tbi-ops-alarm-triggerEventBridge RuleCloudWatch alarm → Step Function
tbi-ops-honeypot-queue-processorEventBridge RuleEvery 5 min → drain queue → WAF block
tbi-ops-bedrock-analyze-scheduleEventBridge RuleEvery 5 min → AI threat analysis
tbi-ops-guardduty-high-findingEventBridge RuleGuardDuty severity ≥ 7 → immediate AI analysis
tbi-ops-daily-digestEventBridge Rule6 AM EST → daily operational digest
tbi-ops-weekly-digestEventBridge RuleMonday 7 AM EST → weekly "Week in Review"
tbi-autoops-blocked-ipsWAF IP SetAuto-blocked IPs from honeypot + AI analysis
tbi-ops-notificationsSNS TopicOperational alerts ([INFO], [WARNING], [CRITICAL], [SELF-HEALED])
4 Anomaly DetectorsCloudWatch MLRequest rate, latency, error rate, cache hit rate

Design Principles

10. Mission

100% of revenue funds freedom from brick kiln debt bondage in Pakistan through Cross Power Ministries of Pakistan.

The Trinity Beast Infrastructure is named in honor of the Father, Son, and Holy Spirit — built to serve both developers and the least of these.