Design Data Freshness & Refresh

Start by pinning down what "fresh" is worth and what it costs. A linked account is only useful if the balance and transactions the app reads are recent, so on the surface the answer looks easy: refresh everything, all the time. The cost side kills that instantly. Every refresh is a live call to a bank we do not control, each institution rate-limits us, and there are more than twelve thousand of them behind hundreds of millions of live connections. Refresh too aggressively and we exhaust an institution's budget, get throttled or blocked, and degrade freshness for every user on that bank. Refresh too lazily and the data goes stale. The whole design is finding the schedule that keeps data current enough while staying inside a fixed, per-institution supply of calls.

Two forces shape every later decision. The first is scarcity. Calls to any one institution are capped, and we can't raise the cap, so refresh capacity is a budget to spend. The second is skew. Freshness is not equally valuable across accounts. A user actively using an app that reads their balance twice an hour needs current data. An account nobody has touched in three months does not. And a balance check right before money moves matters far more than a routine nightly sync. So the design cannot treat every connection the same. It has to spend a scarce budget where freshness is worth the most, which means prioritizing, not just polling.

The Plaid angle

Plaid runs this loop for real, at roughly one to four institution checks a day. The interviewer grades whether you keep data current without becoming the reason a bank throttles Plaid. Healthy Items refresh on the order of once a day, and /accounts/get returns a cached balance as of the last successful update. /accounts/balance/get forces a real-time pull. The scheduler reads item.status.transactions.last_successful_update as its freshness marker. Put the budget on the board early.