Skip to main content

96. Python Service for TA-Lib Integration

Status: Accepted Date: 2025-07-06

Context​

Technical analysis is a core requirement for the Mercury system. We need to calculate dozens of complex technical indicators (RSI, MACD, Bollinger Bands, etc.). The industry-standard library for this is TA-Lib, which is written in C++ and has mature, well-tested Python bindings. While there are some TypeScript ports of TA-Lib, they are often less complete, less performant, or less battle-tested than the original Python version. We need to decide how to access the power of TA-Lib from our TypeScript-based backend.

Decision​

We will create a dedicated, separate microservice in Python called mercury-ta.

  • This service's sole responsibility will be to expose the TA-Lib library over a simple REST API (using FastAPI).
  • The main TypeScript backend (Minerva module) will make HTTP requests to this mercury-ta service to get technical indicator calculations.
  • The mercury-ta service will be a small, stateless application that takes market data as input and returns the calculated indicator data as JSON.

This creates a clean "language boundary," allowing us to use the best tool for the job (Python for numerical computation, TypeScript for application logic) without mixing languages in the same process.

Consequences​

Positive:

  • Leverages Best-in-Class Library: We can use the official, highly optimized, and battle-tested TA-Lib library without compromise.
  • Clean Separation of Concerns: The complex numerical calculations are isolated in a dedicated service. The main application doesn't need to worry about the complexities of financial mathematics.
  • Polyglot Architecture: Allows us to use the right language for the right task, leveraging the strengths of both Python's data science ecosystem and TypeScript's application development capabilities.
  • Independent Scaling: If indicator calculations become a bottleneck, we can scale the mercury-ta service independently of the main application.

Negative:

  • Adds a Microservice: This introduces the overhead of an additional service to deploy, monitor, and maintain.
  • Network Latency: Communication between the main app and the mercury-ta service happens over the network, which is slower than in-process calls.
  • Data Serialization Overhead: We have to serialize market data to send to the Python service and deserialize the resulting indicator data, which adds a small amount of overhead.

Mitigation:

  • Simple, Stateless Service: The mercury-ta service is designed to be extremely simple and stateless, which minimizes its maintenance overhead. It will be deployed as a lightweight container.
  • Caching: The results from the mercury-ta service will be heavily cached in Redis by the Minerva module. The service will only be called for new or stale data, which significantly reduces the impact of network latency. For a given symbol and timeframe, the indicators only need to be calculated once per new candle.
  • Keep it Internal: The mercury-ta service is a purely internal service. It is not exposed to the public internet, and communication will happen over a low-latency internal container network.