Trading Bot using GCP infrastructure
A cloud-based trading solution leveraging GCP infrastructure for automated market analysis and execution.
Overview
This project is an end-to-end, automated trading system architected entirely on Google Cloud Platform using an asynchronous, event-driven microservices model. Built for high resilience, fault tolerance, and horizontal scalability, the platform orchestrates scheduled multi-timeframe market data ingestion, quantitative trade signal evaluation, dynamic risk management, and live order execution.
Each phase of the pipeline is decoupled using Cloud Pub/Sub, Cloud Functions, and containerized Cloud Run services—persisting normalized OHLCV data in Firestore, logging analytical decisions in BigQuery, and dispatching real-time notifications to Discord.
To satisfy strict exchange API security requirements, the execution service routes through a custom VPC, Cloud Router, and NAT Gateway to guarantee a reserved, whitelisted static IP address. The entire cloud ecosystem, networking topology, and IAM access controls are managed 100% via Terraform (IaC).
System Architecture
1. Ingestion & Triggering
- Cloud Scheduler triggers execution on an hourly cron schedule.
- Invokes the
data-ingestion-trigger-cfCloud Function. - Reads configured market pairs/symbols from a central configuration file.
- Publishes an individual message per symbol to the
data-ingestion-trigger-psPub/Sub topic to enable parallel downstream processing.
2. Data Fetching & Storage
data-fetcher-cfCloud Function triggers via Pub/Sub subscription.- Extracts symbol payload and fetches multi-timeframe OHLCV data (
1h,4h,1D). - Persists normalized candlestick data directly into Firestore.
- Publishes a completion event to the
data-ingested-psPub/Sub topic signaling data readiness.
3. Trade Strategy & Analysis
trade-analyzer(Cloud Run) consumes fromdata-ingested-ps.- Retrieves latest OHLCV market history from Firestore.
- Computes trade signals (
BUY/SELL/HOLD), dynamic Stop Loss (SL), and Take Profit (TP) levels. - Logs decision metrics into BigQuery for backtesting & analytics.
- Publishes executable signals to
trade-analysis-finished-psand alerts a Discord channel for actionable signals.
4. Order Execution & Auditing
order-executor(Cloud Run) listens totrade-analysis-finished-ps.- Performs pre-trade risk and sanity checks (balance, slippage, validation).
- Authenticates and routes live market orders directly via exchange APIs.
- Sends real-time execution receipts and order confirmations to Discord.
Key Technical Learnings & Engineering Takeaways
Building an event-driven, automated trading pipeline required moving beyond simple scripting to architecting production-grade cloud infrastructure. Here are the core architectural and infrastructure concepts mastered throughout this project:
01. 100% Infrastructure as Code (IaC) with Terraform
To ensure repeatability, avoid configuration drift, and maintain a fully declarative setup, the entire GCP ecosystem was provisioned and managed using Terraform:
- Automated provisioning of
Cloud Functions(gen2) and containerizedCloud Runmicroservices. - Orchestrated decoupled communication via
Pub/Subtopics, push/pull subscriptions, and dead-letter queues. - Configured
Cloud Schedulercron jobs with fine-grained IAM service account bindings and least-privilege permissions. - Managed modular state files to cleanly isolate network, ingestion, and compute layers.
02. Serverless Networking & Egress IP Whitelisting
Most crypto and financial exchange APIs strictly require API keys to be tied to a whitelisted, static IP address for security. Since serverless workloads (Cloud Run) dynamically scale across dynamic IP pools, a custom VPC egress route had to be architected:
- Provisioned a dedicated Custom VPC network with a private subnet.
- Reserved a Static External IP address in GCP.
- Configured a Cloud Router and Cloud NAT Gateway mapped to the reserved static IP.
- Attached a Serverless VPC Access Connector to route all outbound traffic from the
order-executorCloud Run instance through the NAT gateway, ensuring a reliable and deterministic origin IP for exchange execution.
03. Decoupled, Resilient Event-Driven Architecture
Splitting the pipeline across isolated stages (triggering → fetching → analysis → execution) via Pub/Sub ensured that downstream rate-limits or market data latency did not block upstream scheduling. Additionally, separating the compute-heavy market strategy calculations from the order executor allowed strict security and network isolation for the service handling live capital.