Building BlackOrigin: A Scalable Trading Bot for SaaS Marketplaces

We built BlackOrigin, a SaaS trading automation platform designed to execute lightning-fast trades on Bybit, powered by real-time TradingView signals.

The mission was simple yet demanding:

“Execute buy and sell orders instantly, size positions optimally, and compare cross-market prices — all while ensuring safety, reliability, and low latency.”

This post walks you through the architecture, technology choices (especially RabbitMQ), implementation highlights, hard lessons learned, and the results achieved.

🧭 Project Overview

BlackOrigin is a scalable SaaS trading application built for high-volume, real-time automated trading.
It listens to TradingView signals, computes trade quantities and risks, executes orders on Bybit, and continuously compares prices across multiple exchanges to optimize trading outcomes.

Core Capabilities

⚡ Real-Time Signal Processing: Instantly reacts to TradingView alerts.

🔁 Automated Trade Lifecycle: Signal reception → position sizing → execution → confirmation → monitoring.

🌐 Cross-Market Price Comparison: Checks multiple exchanges for optimal trade execution.

🔒 Concurrency Safety: Redis-based distributed locks prevent overlapping trades.

🧠 Resilience & Observability: Prometheus, Grafana, and Loki ensure transparent monitoring and error recovery.

📢 User Notifications: Telegram, email, and browser alerts (via OneSignal).

🚨 Error Alerts: Slack notifications instantly notify admins and superadmins of system errors.

🧩 Technology Stack

TradingView signals arrive fast — sometimes sending exit signals before entry trades are fully executed or when an entry signal fails.
To maintain consistent, safe trading logic, order dependencies must be preserved.

Rule: “An exit signal must never execute unless the corresponding entry trade succeeded.”

The Real Problem

1. TradingView sends ENTRY → system enqueues entry job.
2. Entry job fails (timeout/API error).
3. The exit signal arrives soon after.
4. Without correlation, the bot tries to close a trade that never opened → false or damaging orders.

Limitations of Laravel’s Default Queue

• ❌ No built-in message correlation (entry ↔ exit).
• ❌ No dead-letter exchanges (DLX) for structured retries.
• ❌ No conditional routing or delayed requeue logic.
• ❌ No management UI for inspecting or replaying messages.
• ❌ Manual DB checks needed — inefficient and error-prone.

Why RabbitMQ Wins

✔ Native support for dependency-based routing
✔ Built-in delayed retries and DLX
✔ Strong message ordering and visibility
✔ Full control via management UI
✔ Scales horizontally for live trading systems

⚙️ Architecture & Workflow (High-Level)

1. TradingView sends a signal via webhook or REST endpoint.
2. The backend normalizes the signal and enqueues it in RabbitMQ.
3. Worker consumers calculate trade size and place orders on Bybit.
   
4. Redis distributed locks ensure no conflicting trades occur for the same symbol.
   
5. Prometheus, Grafana, and Loki handle monitoring and logs.
   
6. Notifications are pushed to users and admins in real time.

🚀 Implementation Highlights

1. Concurrency Safety

Redis distributed locks serialize operations to prevent race conditions (e.g., two simultaneous signals for the same pair).

2. Retry & Idempotency

Each job uses unique idempotency keys, ensuring retries never cause duplicate executions.

3. Queue Specialization

RabbitMQ queues are separated by task type and priority — entry, exit, and settlement — ensuring ordered and controlled message flow.

4. Data Aggregator

A dedicated microservice normalizes price feeds from multiple exchanges, merging them into a canonical market feed for real-time price comparison.

5. Real-Time Frontend

Next.js frontend receives live WebSocket updates on trade status and price changes for a seamless dashboard experience.

🧠 Challenges & Lessons Learned

1. Payment Integration Complexity

Integrating multiple gateways (Stripe, AfterPay, Zip, Klarna, Volet) required handling different currencies, payment flows, and asynchronous webhooks.

Solution:

• Added multi-currency validation layers.
• Implemented conversion and reconciliation logic.
• Enhanced webhook retry and logging systems.

2. Queue Ordering & Concurrency

Ensuring entry-before-exit message flow in concurrent systems was critical.

Solutions:

• Created priority queues and routing keys for order-sensitive jobs.
• Used Redis locks and idempotency keys to enforce sequencing and avoid duplication.

3. Real-Time Multi-Exchange Synchronization

Different exchange APIs had varying latencies and formats, complicating trade reconciliation.

Solutions:

• Built a data aggregator to normalize and timestamp feeds.
  
• Optimized WebSocket multiplexing to reduce latency.
• Designed a lightweight reconciliation loop to match trade executions with market snapshots using tolerance windows.

📊 Results & Impact

✔ Low-Latency Execution: Trades executed in real time, even under heavy signal loads.
✔ Reliable Payment Support: Seamless integration of fiat and crypto gateways with secure webhook recovery.
✔ Scalable Architecture: RabbitMQ + Redis + Worker clusters enabled horizontal scalability.
✔ Robust Operations: Retry, idempotency, and distributed locks reduced trade conflicts drastically.
✔ Maintainable Foundation: Modular architecture supports future expansion to new exchanges, markets, and strategies.

Building BlackOrigin wasn’t just about coding a trading bot — it was about designing a scalable, fault-tolerant, and observant SaaS architecture capable of handling real-world trading chaos.

By leveraging RabbitMQ, Redis, and observability stacks, BlackOrigin achieved speed, stability, and transparency — three pillars essential for any automated trading platform.