Design Mint.com

Mint is a personal finance product that connects to its users’ external bank and credit-card accounts, imports their transactions into a single view, automatically categorizes them, and displays monthly budget progress. The core architectural challenge is that the most critical upstream data source—the bank—is outside our control, imposes rate limits, and responds slowly, forcing the system to deliver a real-time feel while operating mostly on cached, slightly-stale data.

Requirements

The system's bottleneck is the bank, not our own compute infrastructure. We cannot solve a data freshness problem by scaling horizontally when the external dependency itself caps how often we may call it.

Functional requirements

• Users link external bank or card accounts; the system fetches their transactions without exceeding the bank's per-account rate limits.
• Users view a paginated, filterable transaction history spanning all linked accounts.
• Users create and update monthly budgets per category and see their month-to-date spending compared against that budget.
• Users receive an alert whenever month-to-date spending in a category passes a configurable threshold.
• The system generates a monthly spending report for each user (spending by category, top merchants, budget overruns) and serves it on demand.
• Authenticated read traffic is served from any healthy region, and the system remains available to users when an entire data center fails.

Out of scope (below the line)

• Money movement, ACH transfers, bill pay, or any write-back to bank accounts.
• Investment portfolio analysis, net-worth tracking, and credit-score features.
• Tax reporting, 1099 generation, and accountant export workflows.
• Receipt OCR and manual transaction entry from photos.
• ML-driven personalized advice and fraud-detection scoring.
• Building the bank-side OAuth or screen-scraping integrations themselves. We treat the aggregator (Plaid-like) as an external dependency with a known contract.

Non-functional requirements

• Each linked account is polled at most ~4 times per day, and the system never bursts into the bank on user logins.
• Visible transactions are at most a few hours stale relative to the bank, and the contract is near real time, not live.
• P99 of transaction history and budget view returns under 300 ms from the warm read path.
• A cached monthly report is served under 500 ms, and first-time generation of one user's report completes in a few seconds.
• Plan for ~50M registered users, ~10M daily active users, ~3 linked accounts per active user, and ~50 transactions per account per month.
• Peak read traffic sits in the low six digits, roughly ~100k QPS.
• Target 99.95% availability for the user-facing read path, surviving the loss of one full region without manual data restore.
• Pulled transactions and budgets are durable before acknowledgment and cannot silently disappear from a user's history.
• Bank credentials and tokens are encrypted at rest with a KMS-backed key and never appear in logs.

Back-of-the-envelope estimation

[!IMPORTANT] The two load numbers that drive every later decision are ~1.4k/sec of aggregator calls and ~100k peak read QPS. They differ by almost two orders of magnitude. That gap is why ingest and read serving must be designed as separate planes.