Designing a Bitcoin Arbitrage Trading System: Architecture, Tools, and Real-Time Insights

·

In the early days of cryptocurrency trading—particularly around 2014 and 2015—arbitrage opportunities between exchanges were abundant. Price discrepancies for Bitcoin across platforms often exceeded 5%, making automated arbitrage a low-effort, high-reward strategy. Fast forward to today, and those margins have dramatically narrowed. Competition has intensified, latency matters more than ever, and only well-optimized systems operated by experienced players remain profitable.

This article dives into the technical architecture of a modern Bitcoin arbitrage trading system, focusing on scalability, real-time data processing, and smart tool integration. We’ll explore how to design a robust, fault-tolerant system using Elixir, leverage external monitoring tools for visualization, and build flexibility into decision-making workflows—all without reinventing the wheel.

Core Keywords

Observing Market Data: The First Step in Arbitrage Feasibility

Before any trade logic is implemented, the foundation of any arbitrage system lies in accurate, timely market data. While domestic exchanges have largely withdrawn due to regulatory pressures, international platforms like Bitfinex, Kraken, Bithumb, and Korbit continue to offer REST APIs—and in some cases, WebSocket endpoints—for accessing real-time price feeds.

These APIs are generally straightforward to use despite sparse documentation. Each provides bid/ask prices, order book snapshots, and trade histories. The challenge isn’t in fetching the data—it’s in normalizing it across currencies (e.g., KRW from Bithumb vs. USD from Bitfinex) and processing it efficiently at scale.

👉 Discover how real-time market data can power your trading edge

Why Elixir? Building Scalable and Resilient Systems

After initial prototyping in Node.js, I transitioned the entire project to Elixir on the Erlang VM, leveraging the OTP framework. Here's why:

1. Built-in Microservices Architecture

Each exchange feed runs as an isolated GenServer process. This loose coupling allows individual components (like Bithumb or Bitfinex connectors) to fail without crashing the entire system. More importantly, currency conversion—say from KRW to USD—can be handled by a dedicated service that broadcasts updated rates across the application.

2. Native PubSub for Decoupled Data Flow

Using Phoenix.PubSub, we separate data ingestion from data consumption:

This eliminates the need for external message brokers like ZeroMQ or RabbitMQ, reducing complexity and operational overhead.

3. Concurrency and Fault Tolerance

Erlang’s lightweight processes handle thousands of concurrent connections with minimal memory footprint. Combined with supervisor trees, the system self-heals when components crash—critical for unattended trading operations.

Making Data Actionable: Visualization Over Abstraction

Raw numbers alone—such as “10 arbitrage opportunities >0.5% in the past hour”—are abstract and hard to interpret. After accounting for transaction fees (typically 0.1%–0.25% per side), many apparent spreads vanish. To evaluate true feasibility, you need contextual insight.

As the old saying goes: “No picture, no husband.” In trading terms: no visualization, no conviction.

Rather than building a custom frontend—which quickly becomes a maintenance burden—I opted to integrate with Datadog, a tool typically used for application performance monitoring (APM). By treating market data as metrics, we gain powerful time-series visualization out of the box.

Sending Metrics to Datadog

A simple subscriber listens to incoming price ticks and forwards them using DogStatsD:

abt.xchg.btc.bid:4182|h|#bitfinex  
abt.xchg.eth.bid:301.93|h|#bitfinex  
abt.xchg.btc.bid:4009.07|h|#bithumb

Each metric includes:

Once ingested, Datadog lets us:

👉 See how visual analytics can transform raw trading data

The result? Clear, real-time visibility into arbitrage windows. For example, a persistent 2–3% spread between Bitfinex and Bithumb becomes immediately actionable.

System Architecture Overview

The full system consists of four main applications:

  1. Exchanges
    Fetches real-time data from multiple APIs and publishes normalized ticks via PubSub.
  2. Catcher
    Subscribes to price events and persists data—both to Datadog (for visualization) and InfluxDB (for low-latency analysis).
  3. Simulator (in development)
    Simulates trades using live or historical data, applying realistic fees and network delays. Can spawn virtual traders ("NPCs") with varying strategies to compare performance.
  4. Trader (planned)
    Executes actual trades when conditions meet predefined thresholds.

Currently, Exchanges and Catcher are functional; Simulator is under active development.

Why InfluxDB Alongside Datadog?

While Datadog excels at visualization and alerting, it introduces latency—typically 15–20 seconds—due to internal batching in its agent. This delay is acceptable for retrospective analysis but problematic for real-time decision-making.

Enter InfluxDB, a time-series database we fully control:

Grafana now supports alerting via webhooks. Imagine writing a query like:

SELECT difference("price") FROM "btc_usd" WHERE "exchange" =~ /(bitfinex|bithumb)/

When the spread exceeds 1%, Grafana triggers an alarm that calls a webhook—potentially initiating a real trade. No code changes needed—just a configuration update.

This dual-storage approach gives us the best of both worlds:

Frequently Asked Questions

Q: Is arbitrage still profitable in 2025?

A: Yes—but only with optimized infrastructure. Margins are thin (often <1%), so success depends on low-latency data access, precise fee modeling, and rapid execution.

Q: Can this system work with other cryptocurrencies besides Bitcoin?

A: Absolutely. The architecture supports any tradable asset—Ethereum, XRP, Zcash—with minimal configuration changes.

Q: How does the system handle exchange API failures?

A: Thanks to OTP supervision trees, failed processes restart automatically. Missing a few ticks may mean lost opportunities, but not system failure.

Q: Why not build a custom UI instead of using third-party tools?

A: Frontend development is time-consuming and prone to technical debt. Leveraging mature tools like Datadog and Grafana accelerates development and ensures reliability.

Q: What prevents front-running or missed execution?

A: Simulated trading includes network delay modeling and slippage estimation. Live trading would require co-location or direct API relationships with exchanges.

Q: How much code does the system require?

A: Currently around 700 lines of Elixir. The modular design keeps complexity manageable even as features expand.

Final Thoughts: Tools, Time, and Flow

One surprising takeaway? We often say we lack time—but what we really lack is interest. On the night this prototype was built, I had meetings and training—but still found six focused hours to code. Why? Because the challenge was engaging.

The lesson for product teams: Design systems that spark curiosity. Use tools creatively—like repurposing APM software for trading analytics—and embrace composability over monolithic builds.

This project proves that with the right stack—Elixir for resilience, PubSub for decoupling, and smart external tools for visualization—you can prototype powerful financial systems rapidly and sustainably.

👉 Turn market insights into action with advanced trading tools