Cache resource heavy endpoints #21

New issue

Closed

opened 2026-02-27 10:47:19 +00:00 by fabioth · 3 comments

fabioth commented

2026-02-27 10:47:19 +00:00

(Migrated from gitlab.esvedra.one)

{width="900" height="522"}

The current situation is that the homepage makes five calls to populate all the widgets. Four of those calls are to the /analytics/top-performers endpoint. These calls are resource‑intensive, especially when the user selects an exchange with many stocks (e.g. NASDAQ). Also, every time the user visits or refreshes the page, those calls are made again. This results in quite a big queue which halts all the endpoints. In my opinion, we can cache these resource‑heavy endpoints because they do not change very often, particularly the monthly and yearly performer data.

![image.png](/uploads/17e271d62736cc351b71fc99bc9f1b15/image.png){width="900" height="522"} The current situation is that the homepage makes five calls to populate all the widgets. Four of those calls are to the `/analytics/top-performers` endpoint. These calls are resource‑intensive, especially when the user selects an exchange with many stocks (e.g. NASDAQ). Also, every time the user visits or refreshes the page, those calls are made again. This results in quite a big queue which halts all the endpoints. In my opinion, we can cache these resource‑heavy endpoints because they do not change very often, particularly the monthly and yearly performer data.

fabioth commented

2026-02-27 10:47:58 +00:00

(Migrated from gitlab.esvedra.one)

changed the description

fabioth commented

2026-02-27 10:50:11 +00:00

(Migrated from gitlab.esvedra.one)

marked this issue as related to #19

gertjan (Migrated from gitlab.esvedra.one) closed this issue

2026-02-27 18:50:15 +00:00

project_1_bot_053fc026be1655bf3cd800152d0cdead commented

2026-02-27 19:02:37 +00:00

(Migrated from gitlab.esvedra.one)

Fixed in 6bc219b with two changes to src/api/cache.py: (1) in-flight request deduplication — concurrent requests for the same cache key now coalesce onto a single asyncio Future instead of all hitting the DB simultaneously, preventing the thundering herd from the homepage's four parallel top-performers calls; (2) per-endpoint TTL support, used to give top-performers a 1-hour TTL instead of the global 5 minutes, since the data barely changes within a trading day.

Fixed in 6bc219b with two changes to `src/api/cache.py`: (1) in-flight request deduplication — concurrent requests for the same cache key now coalesce onto a single asyncio Future instead of all hitting the DB simultaneously, preventing the thundering herd from the homepage's four parallel `top-performers` calls; (2) per-endpoint TTL support, used to give `top-performers` a 1-hour TTL instead of the global 5 minutes, since the data barely changes within a trading day.