[ CAPITAL_MARKETS ]

Market Data API Microservices

2026Data Pipelines & AutomationCapability

What it is

The data layer sitting between scraped market data and the products that consume it.

Client work is shown without identifying imagery

[ THE_PROBLEM ]

Why this existed

When three applications query the same database directly, a schema change breaks all three at once and nobody knows which queries exist.

[ WHAT_WE_BUILT ]

What we built

Schema-managed API services over Postgres and MySQL, deployed separately from the front ends so the ingestion pipeline, the public site and the admin panel all read through one contract rather than three sets of direct database queries.

Schema-managed API services over relational databases
Deployed separately from consuming front ends
Single read contract shared by ingestion, public site and admin panel

[ HOW_IT_IS_USED ]

How a company uses it

Once more than one application reads the same data, an API boundary is what stops a schema change from breaking three products at once.

Built with

ExpressPrismaPostgresMySQL

[ COMMON_QUESTIONS ]

Questions clients ask

Why not let applications query the database directly?

It works until there is more than one. After that, every schema change is a coordinated release across applications nobody has a full inventory of. An API boundary turns that into a versioned contract.

Does this add meaningful latency?

A little, and it is almost always worth it. The exception is genuinely latency-critical paths, which should be identified explicitly rather than used to justify skipping the boundary everywhere.

How do you version the API?

Additively wherever possible — new fields rather than changed ones — with explicit versioning for breaking changes. The discipline matters more than the mechanism.

[ RELATED_WORK ]