This is Part 1 of a two-part case study: one real platform, taken apart piece by piece. Part 1 covers the backbone that every product shares: the web apps, the login, the API, the shared library, the worker, the database, and the deployment pipeline. Part 2 covers what runs on top: trading, investing insights, charts, career, and the AI guardrails.
Everything below describes Algomi as it is built, from its code and design notes. Where a part is still a plan, the text says so.
1. A campus with one ID card
Picture a school campus. There is a library, a sports hall, a science lab, and an art room. Each building has its own staff and its own rules. But every student carries one ID card that opens every door. There is one front office that answers questions and keeps the records. And at the back, a caretaker stays on shift with the keys and the alarm panel, but only during school hours.
Algomi is built like that campus.
The buildings are five web apps: the suite home and admin console, Trade and Invest, Career, Charts, and this Blogs site.
The ID card is one login that works in all of them.
The front office is one API (application programming interface) service. It decides what is allowed and talks to the database.
The records room is one MySQL database.
The caretaker is a worker service. It holds long-lived connections to brokers and Telegram and runs scheduled jobs.
Where the analogy stops: a school guard can be talked into letting someone in. Algomi's "ID card" is a signed cookie that a computer checks the same way every time, and, as section 4 shows, signed does not mean secret.
Algomi is a multi-product platform for Indian markets: signal-driven trading through several brokers, investing insights, an AI career copilot, and charting with backtesting. Section 2 ends with the whole platform in one picture.
A few words we will use:
Word
Meaning here
Stateless
A service that keeps nothing important in its own memory between requests, so any copy can answer any request
Worker
A background service that keeps running to hold connections and run jobs, instead of answering one request and stopping
WebSocket
A connection that stays open so the other side can push updates instantly
Lease
A claim on a job that expires unless it is renewed, so a crashed owner loses it automatically
Wheel
A packaged, versioned Python library, installed with pip
2. Meet the pieces
Piece
Runs as
Job
Suite (algomi-suite)
Next.js on Cloud Run at algomi.in and admin.algomi.in
The shared header, product switcher, and theme toggle
Shared library (algomi-shared)
Python wheel built from the API repository
Database access, broker adapters, jobs, the Pine interpreter, the scanner
The rule of thumb: screens draw, the API decides, the worker holds connections, the database remembers.
Here is the whole campus in one picture, with every piece from the table in its place:
Follow the numbers for one trade signal; only the main paths are drawn. Arrows into the shared library are in-process calls; arrows out of it are network calls. Solid arrows are calls, dashed arrows are internal service-to-service calls.
You've reached the free preview of this post.
Subscribe to the Blogs plan (₹99/mo) — or use any Algomi Suite, Career, Investor, or Trader plan — to keep reading.
