A faster path to market data

The problem

A financial product fetched stock data and order books from external financial platforms. Waiting for that information affected how responsive the product felt. Repeated reads could repeat the same upstream fetching work.

The performance issue crossed a system boundary: improving the interface alone would leave the external dependency in the path between a request and its response.

My contribution

I worked on backend data fetching and added a cache so the application could reuse market data it had already retrieved. My contribution covered the fetching and reuse path behind the application API.

Decisions and approach

Put reuse behind the API

I added caching to the backend fetching path. Once data had been fetched and was suitable to serve, the application could reuse it instead of depending on another upstream request for every repeated read.

Keeping reuse behind the application API meant the frontend did not need to manage a separate cache for each financial platform. The responsibility stayed close to the fetching logic.

Separate response speed from data freshness

A quickly returned snapshot is not necessarily current. Response time describes how long the user waits; freshness describes the age of the information. Upstream feeds and refresh behavior still determine how recent the available data is.

The trade-off

Fetching upstream on every repeated read keeps the external request in the response path. Reusing previously fetched data reduces that repeated work, while requiring a separate assessment of whether the snapshot is suitable for the task.

The useful distinction is between removing repeated fetching and claiming live market data. This change addressed the former.

The data path

A simplified read illustrates where the cache sits:

1. The backend retrieves market data from a financial platform.
2. A reusable copy is kept in the backend cache.
3. The application API supplies data to the stock-data and order-book views.
4. Repeated reads can reuse suitable fetched data rather than repeat the upstream request.

Market-data reuseSimplified flow

1. External sourcesFinancial platforms
2. My contribution / ReuseBackend cache
3. Serve throughApplication API
4. Product views
   Stock dataOrder book

Outcome

The change reduced repeated fetching and helped make stock-data and order-book views more responsive.

Evidence boundary: This is a qualitative account of my backend contribution. Latency measurements, cache-hit rates, specific cache technology, and refresh settings are not available in the public account. The diagram explains the data path rather than a complete production architecture.

What this demonstrates

When a screen feels slow, follow the request through the interface, API, and external dependencies. Here, reducing repeated backend work improved the path to the screen. Response speed and data freshness remained separate concerns.