Algomi Architecture, Part 2: Trading, Insights, Charts, Career, and the AI Guardrails

This is Part 2 of a two-part case study. Part 1 built the campus: five web apps, one login, a stateless API, a shared library, a worker that sleeps at night, and one database. This part goes inside the classrooms. It covers the engines that run on that backbone: trading, investing insights, charts, career, and the AI layer that all of them share. It ends with the guardrails that hold it together.

Part 1 explains the API, the worker, and the database, and it opens with a diagram of the whole platform, so start there if you want the big picture first. Part 2 leans on those pieces. For the AI parts, LLM serving and inference cost and AI evals and observability are good companions. As before, everything below describes Algomi as it is built, and says clearly where something is still a plan.

A few words we will use:

1. From a Telegram message to a broker order

Signals arrive two ways: free-text messages from Telegram channels, handled by the worker, and TradingView alert webhooks, handled by the API.

sequenceDiagram
    participant T as Telegram channel
    participant L as Worker listener
    participant P as Parser
    participant K as Broker adapter
    participant D as MySQL
    T->>L: Free-text signal
    L->>P: Fix typos and shorthand
    P-->>L: Structured trade intent
    L->>K: Place the entry order
    K-->>L: Broker order id
    L->>D: Save one row with status Processing
    K-->>L: Fill update by WebSocket, REST poll as fallback
    L->>D: Row becomes Open with the real fill price
    L->>K: Place exits as broker-side OCO pairs

Reading the diagram. Follow one signal left to right and down. The worker listener receives free text from the Telegram channel and asks the parser to turn "nifty 18000 c3" into a structured intent. The listener sends the entry to the broker adapter, gets a broker order id back, and saves one row marked Processing in MySQL. The fill arrives from the broker's WebSocket (REST polling is the fallback), the same row becomes Open with the real price, and only then are exits placed at the broker as OCO pairs. The order of the last four lines is the safety: no exit is placed for a fill that has not been confirmed.

The parser is a language model helper that turns messy text like "nifty 18000 c3" into a structured signal. It goes through the AI gateway from section 5 as a task whose data class is PUBLIC, because a channel message holds no user data. Each broker (Fyers, Kite, Dhan, Delta, and Shark) has its own adapter module, because their order types and products differ. The team's stated goal is to keep shared rules, such as closing a trade, in one function instead of five broker-specific copies.

Five design decisions carry most of the weight. The team's design note covers the Fyers path in the most detail, so decisions 2 to 4 describe it. Other brokers are meant to follow the same one-row lifecycle, but they differ in order types and support.