Connect an account
The account request follows the web path to Accounts API and the accounts table.
Interactive diagram · architecture
The account request follows the web path to Accounts API and the accounts table.
Slow extraction moves to a queue, then the worker stores, categorizes, and aggregates the result.
Monthly spending drives Budget Service, which can send a notification.
The read path checks memory first and falls back to SQL read replicas.
The user-facing Mint application.
It sends account and read requests to the Web Server. It receives completed account data and summaries.
Users make transactions daily, but few visit the site daily.
It resolves the Mint domain for the client.
It receives the client lookup. It directs the client toward Mint's front door.
DNS is one of the components added to address scalability issues.
A cache for static content.
It serves static content from the Object Store to the client. It reduces work on the Web Server.
Static content can be served from the Object Store and cached on the CDN.
A replicated front door for application traffic.
It receives client traffic after DNS. It forwards requests to the Web Server fleet.
Load balancers and multiple Web Servers address bottlenecks.
A reverse proxy for Mint requests.
It receives client traffic from the Load Balancer. It forwards account work to Accounts API and reads to Read API.
Internal load balancers are not shown to reduce clutter.
A seller-to-category dictionary.
Transaction Extraction Service sends it each transaction. It hands a category back for the Budget Service and SQL Database.
Manual category overrides can supply sellers not initially seeded in the map.
The service that calculates monthly spending by category.
It receives categorized transactions from Transaction Extraction Service. It passes budget status to Notification Service and stores monthly spending.
A generic budget template means only user overrides need storage.
A service that tells users about budget and extraction events.
It receives budget status from Budget Service and completion events from Transaction Extraction Service. It sends notices to the user asynchronously.
Budget notifications do not need to be instant.
A worker that extracts transactions for an account.
It pulls jobs from Queue. It writes raw logs to Object Store, calls Category Service and Budget Service, then updates SQL Database.
Extraction can take awhile, so asynchronous work adds complexity.
A holding area for slow account work.
Accounts API puts extraction work on it. Transaction Extraction Service pulls the job and starts processing.
It lets the service extract transactions asynchronously, but adds complexity.
The API that accepts financial account details.
It receives account requests from the Web Server. It updates the SQL Database accounts table and queues extraction work.
Account additions and removals are relatively rare.
The API for summaries and transactions.
It receives read requests from the Web Server. It checks Memory Cache, then fetches from SQL Read Replicas on a miss.
Popular content should use Memory Cache instead of the database.
Memory for sessions, aggregate stats, and recent transactions.
Read API checks it first. On a SQL miss, Read API updates it with fetched content.
It helps with uneven traffic and traffic spikes.
The SQL database that stores accounts, transactions, and monthly spending.
Accounts API writes account details here. Transaction Extraction Service writes categorized transactions and monthly aggregates.
A single SQL writer might be tough for transaction writes.
SQL copies that serve read cache misses.
They receive cache-miss reads from Read API. They return summaries and transactions to Read API.
Replicas must not be bogged down with replicating writes.
Storage for raw transaction log files and static content.
Transaction Extraction Service writes raw logs here. CDN can serve its static content to the client.
Running analyses on transaction files can reduce database load.
Detail · follows playback, or click any box or step to pin it
Close · follow playbackClick any box for an explanation, or use Next or Play to walk through the four steps.
The client reaches a Web Server, which sends account information to Accounts API. Accounts API updates the SQL accounts table.
Accounts API queues the slow job. The worker extracts logs, categorizes transactions, aggregates spending, and updates storage.
Budget Service calculates spending by category and asks Notification Service to warn users near or over budget.
Read API checks Memory Cache first. On a miss it fetches SQL data and refreshes the cache.