INDEPENDENT ENGINEERING PROJECT
ZettaBridge
Designing Secure, Multi-Tenant Trading Execution Infrastructure
Backend Engineering / Distributed Systems / Cloud Infrastructure
An independently developed trading infrastructure prototype exploring secure webhook ingestion, multi-tenant backend architecture, broker connectivity, execution workflows, and cloud-native deployment.
Commercial Development Discontinued
ZettaBridge was developed as an independent engineering initiative to explore the technical challenges of webhook-driven trading workflows and broker connectivity.
Commercial development was discontinued after evaluating integration constraints, regulatory considerations, and business feasibility.
The project remains an engineering case study demonstrating backend architecture, software security, API integration, infrastructure automation, and system design.
01 / Project Overview
ZettaBridge was conceived as a platform for processing externally generated trading signals and translating them into structured execution workflows. Independently developed by Surya Pratap Singh, the project connects backend design, a browser dashboard, and infrastructure automation.
The core problem was coordinating untrusted incoming requests with user-specific external integrations: validate the input, establish resource ownership, apply safeguards, route work, and make the resulting status inspectable.
Evidence scope: this study describes a reviewed source snapshot; the references below identify the implementation files inspected. Implementation and test files establish what was written; they do not establish successful live broker execution or production readiness.
02 / Problem & Technical Requirements
The intended design needed authenticated ingestion, tenant-scoped resources, protected credentials, request validation, duplicate suppression, execution coordination, and operational visibility. The evidence supports different levels of completion:
Implemented in source
Token lookup, JWT-protected management routes, resource ownership checks, credential encryption, configurable guards, Redis deduplication, a bounded worker queue, adapter routing, and dashboard code.
Prototype integration paths
Paper execution, direct broker API clients, and Kite Publisher handoff are present. Client code and fixture tests do not confirm unattended live execution for every broker.
Historical deployment
Terraform includes a staging ECS environment and smoke-test scripts. The repository README reports a former AWS deployment that has been shut down. No current running service or independently verified staging pass report is claimed.
Outside verified completion
Production readiness, durable queue recovery, end-to-end exactly-once execution, complete broker reconciliation, and regulatory approval are not established. Planned capabilities are not counted as implemented.
03 / High-Level Architecture
A Go/Fiber API resolves webhook configuration and performs ingress checks. A bounded, in-process queue moves accepted work to workers. Execution adapters separate paper and broker-facing workflows from the HTTP ingestion handler.
- 01 →Signal sourceExternal webhook request; treated as untrusted input.
- 02 →Go APIToken lookup, payload parsing, tenant context, guards, rate limits, and duplicate checks.
- 03 →In-memory worker queueBounded enqueue, worker validation, and execution routing.
- 04 →Execution pathsPaper simulation or broker adapter; Publisher creates a browser handoff.
- 05 →Result persistenceTrade state, rejection details, and ingestion records in PostgreSQL.
- 06Next.js dashboardAuthenticated API views and WebSocket trade updates.
PostgreSQL ↔ API / workers
Users, webhooks, credentials, and execution records.
Redis ↔ API / workers
Webhook caching, rate counters, and time-bounded duplicate suppression. Redis is not the worker job queue.
Source evidence: Ingestion (internal/modules/signals/handler.go) · Worker queue (internal/platform/queue/queue.go).
04 / Verified Technology Stack
- Backend
- Go, Fiber HTTP APIs, WebSockets, Prometheus instrumentation.
- Frontend
- Next.js, React, TypeScript.
- Data
- PostgreSQL persistence and Redis caching, counters, and duplicate claims.
- Infrastructure definitions
- Docker, Terraform, AWS ECS Fargate, ALB, RDS PostgreSQL, ElastiCache Redis, and CloudWatch.
- Security mechanisms
- JWT-protected management access, webhook tokens, resource authorization checks, and AES-256-GCM credential encryption.
Source evidence: Go dependencies (go.mod) · Dashboard dependencies (dashboard/package.json).
05 / Key Engineering Components
Webhook ingestion
The handler hashes the incoming webhook token and resolves configuration through Redis with a PostgreSQL fallback. It validates signal actions and guards, applies rate counters, attempts an atomic duplicate claim, and enqueues without blocking. A successful enqueue returns HTTP 202: acceptance for processing, not execution success.
Source evidence: Signal handler (internal/modules/signals/handler.go) · Redis claims (internal/store/redis.go).
Multi-tenant resource boundaries
Management routes use authenticated user context. Webhook and credential access helpers check ownership; organization-scoped access has separate resource scope logic. Publisher order reads also check the requesting user. This is application-level authorization, not a claim of separate databases per tenant or a completed security audit.
Source evidence: Ownership tests (internal/handler/org_scope_test.go) · Publisher authorization (internal/modules/publisher/handler.go).
Execution workflows and broker boundaries
Workers revalidate action, symbol, and order type before downstream execution. Paper execution is a simulation. Direct API clients are distinct from Kite Publisher, which prepares a basket and returns a pending-confirmation handoff for browser interaction. Publisher tests explicitly cover unsupported cancellation and account-equity operations.
Publisher callbacks and user submission states do not establish exchange fills. The case study does not claim broker endorsement, unattended Publisher execution, or complete trade reconciliation.
Source evidence: Execution modes (internal/domain/broker.go) · Publisher behavior tests (internal/integrations/brokers/zerodha/publisher/executor_test.go).
Credential security
The encryption helper uses AES-256-GCM with a fresh nonce and binds ciphertext to the credential identifier as authenticated data. Tests cover round trips, wrong keys, wrong credential identifiers, and tampering. Encryption at rest complements authorization; it does not remove the need to protect the running application and its secrets.
Source evidence: Credential encryption (internal/platform/crypto/credenc.go) · Security tests (internal/platform/crypto/credenc_test.go).
Dashboard and observability
The Next.js dashboard includes webhook and trade views and Publisher handoff handling. Go code supports WebSocket trade updates, ingestion records, rejection codes, and metrics. These expose application state, which must be distinguished from independently reconciled broker execution state.
Source evidence: Dashboard handoff (dashboard/lib/publisher.ts) · WebSocket tests (internal/handler/ws_trades_integration_test.go).
06 / Infrastructure & Deployment
Docker definitions package the application and dashboard. The staging Terraform configuration defines ECS Fargate services for the application and adapters, an application load balancer, PostgreSQL and Redis resources, networking, security groups, and monitoring.
Public/private subnet and NAT gateway definitions show the infrastructure cost of managed data services and controlled outbound connectivity. These are historical deployment definitions, not evidence of a currently running environment. The repository reports that the AWS infrastructure and hosted dashboard were shut down.
Source evidence: ECS definitions (deploy/deploy-aws-ecs/terraform/staging/ecs.tf) · Network definitions (deploy/deploy-aws-ecs/terraform/staging/vpc.tf) · Historical deployment status (README.md).
07 / Engineering Challenges & Trade-offs
Fast acceptance versus durable delivery
A buffered Go channel keeps enqueue simple and provides back-pressure when full. It is not a durable message broker: accepted jobs in memory can be lost on process failure. Persistent job recovery would require additional design.
Duplicate suppression versus exactly-once effects
Redis claims suppress matching signals for a configured time window. Queue saturation releases the claim. This is narrower than exactly-once execution across application restarts and external brokers.
Availability versus enforcement
At ingestion, Redis failures in rate-limit and duplicate checks are logged and processing can continue. That favors acceptance during dependency problems but weakens safeguards. It is an explicit limitation to evaluate before any operational use.
Common interfaces versus broker differences
A shared execution model reduces coupling, but cannot erase differences between simulation, authenticated API requests, and user-confirmed baskets. Pending confirmation and unsupported operations must remain visible in the domain model.
Credential binding and resource ownership checks address different boundaries: encrypting a value cannot replace checking who may access it. Likewise, separate adapter processes improve separation of concerns while introducing deployment, service-authentication, and monitoring overhead.
Source evidence: Ingestion error handling (internal/modules/signals/handler.go) · Queue back-pressure (internal/platform/queue/queue.go).
08 / Testing & Quality Evidence
- Go tests cover credential encryption and tampering, ownership helpers, execution guards, queue behavior, and Publisher payload validation.
- HTTP-based integration tests exercise broker-authentication failures and WebSocket authentication paths.
- The repository contains k6 load scenarios, security scripts, and staging smoke scripts. Their presence establishes test tooling, not successful historical runs or performance guarantees.
The application test suite and deployment scripts were not executed for this website update. No coverage percentage, throughput figure, staging pass claim, or production reliability metric is asserted. No verified Playwright workflow suite was found in the inspected public dashboard.
Source evidence: Guard tests (internal/guard/guard_test.go) · Integration failure tests (internal/integration/live_queue_auth_test.go) · Staging smoke script (deploy/deploy-aws-ecs/scripts/staging-smoke.sh).
09 / Project Outcome
ZettaBridge progressed through substantial backend, dashboard, and infrastructure implementation. The retained source demonstrates webhook processing, tenant-aware resource handling, credential protection, execution routing, and broker integration approaches.
Commercial development was discontinued after evaluating integration constraints, regulatory considerations, and business feasibility. This is a project-status explanation, not a finding of regulatory noncompliance. The sanitized engineering account is retained here; no service is being offered through this case study.
10 / Engineering Lessons Learned
- Model external constraints early. User-confirmed workflows and direct API calls require different states and user expectations.
- Define security boundaries separately. Identity, resource ownership, credential encryption, and service authorization solve distinct problems.
- Name reliability guarantees precisely. Acceptance, deduplication, durable delivery, and confirmed external execution are different milestones.
- Treat operating cost as architecture. Managed infrastructure and adapter isolation bring maintenance and coordination costs alongside their benefits.
- Separate implementation from feasibility. Working components alone do not establish a viable commercial service; narrowing or discontinuing scope can be a reasoned outcome.
Further work on the case study could add sanitized, reproducible test reports and a more detailed failure-recovery analysis. Those are evidence improvements, not a commitment to restart the product.