system-design-primer
exercise

Mint.com

Design Mint.com: users connect financial accounts, transactions are pulled in and categorized automatically, and users see spending against budgets.

constraints and assumptions
  • 10 million users
  • 10 accounts per user
  • 5 transactions a day per account
  • Categories are recommended and can be corrected
  • Monthly budget by category
  • Service is highly available
work it in four steps
in short

Users connect an account, the service extracts transactions daily, categorizes them, allows manual recategorization, and shows spending against a monthly budget.

10 million users with 10 accounts each at 5 transactions a day is 500 million transactions a day. The extraction runs as a daily batch, not on request.

read: Back-of-the-envelope estimation
from the primer — step 1: outline use cases and constraints

Gather requirements and scope the problem. Ask questions to clarify use cases and constraints. Discuss assumptions.

Without an interviewer to address clarifying questions, we'll define some use cases and constraints.

Use cases

We'll scope the problem to handle only the following use cases

  • User connects to a financial account
  • Service extracts transactions from the account
    • Updates daily
    • Categorizes transactions
      • Allows manual category override by the user
      • No automatic re-categorization
    • Analyzes monthly spending, by category
  • Service recommends a budget
    • Allows users to manually set a budget
    • Sends notifications when approaching or exceeding budget
  • Service has high availability

Out of scope

  • Service performs additional logging and analytics

Constraints and assumptions

State assumptions

  • Traffic is not evenly distributed
  • Automatic daily update of accounts applies only to users active in the past 30 days
  • Adding or removing financial accounts is relatively rare
  • Budget notifications don't need to be instant
  • 10 million users
    • 10 budget categories per user = 100 million budget items
    • Example categories:
      • Housing = $1,000
      • Food = $200
      • Gas = $100
    • Sellers are used to determine transaction category
      • 50,000 sellers
  • 30 million financial accounts
  • 5 billion transactions per month
  • 500 million read requests per month
  • 10:1 write to read ratio
    • Write-heavy, users make transactions daily, but few visit the site daily

Calculate usage

Clarify with your interviewer if you should run back-of-the-envelope usage calculations.

  • Size per transaction:
    • user_id - 8 bytes
    • created_at - 5 bytes
    • seller - 32 bytes
    • amount - 5 bytes
    • Total: ~50 bytes
  • 250 GB of new transaction content per month
    • 50 bytes per transaction * 5 billion transactions per month
    • 9 TB of new transaction content in 3 years
    • Assume most are new transactions instead of updates to existing ones
  • 2,000 transactions per second on average
  • 200 read requests per second on average

Handy conversion guide:

  • 2.5 million seconds per month
  • 1 request per second = 2.5 million requests per month
  • 40 requests per second = 100 million requests per month
  • 400 requests per second = 1 billion requests per month
sourcedonnemartin/system-design-primer / solutions/system_design/mint/README.mdsyncedsynced from donnemartin/system-design-primer@master · 2026-08-16
full solution in the primer ↗