What to Expect in the Block System Design Interview

The Block system design interview asks you to design payment and money movement systems. Mid-level and senior candidates get one design round inside the virtual onsite. The questions are based on Block's products: merchant payments at Square, consumer transfers at Cash App, and installment payments at Afterpay. Correctness matters more here than in most design interviews, because the data is money.

The Question Types Block Asks

Reported and typical questions are about money movement.

• Payment processing. Design the pipeline that takes a card payment from a Square reader to the merchant's balance.
• Peer-to-peer transfers. Design a Cash App style system that moves money between two users instantly.
• Fraud detection. Design a service that flags suspicious transactions in near real time.
• Ledgers. Design the record system that tracks every balance change. A ledger is an append-only list of money movements.
• Reconciliation. Design a job that compares internal records against bank records and reports mismatches.

What Makes Block's Problems Different

Exactly-once behavior. A retried request must never charge twice. The standard answer is idempotency: running the same request twice has the same effect as once. Give every payment request a unique key and reject duplicates.

Strong consistency for balances. Many systems accept stale reads. Balances cannot. A stale read means serving old data after it changed. Say clearly which parts of your design need strong consistency and which do not.

Auditability. Regulators and support teams must trace every cent. Prefer append-only records over updates in place. Deleting or editing history is a defect in this domain.

Failure handling with other companies. Card networks and banks are external systems that fail and time out. A card network, such as Visa, is the system that connects banks to process card payments. Your design needs retries, timeouts, and a queue for stuck transactions. Explain what users see while a transaction waits.

One Example Question: Design a Peer-to-Peer Transfer System

Step 1: Requirements (about 5 minutes). Users send money to each other by username. Transfers appear instant to users. No money is ever lost or duplicated. Assume 10 million transfers per day as a working number.

Step 2: High-level parts. A mobile client, an API gateway, a transfer service, a ledger database, a fraud check service, and a notification service. An API gateway is the single entry point that routes requests to backend services.

Step 3: The transfer path. The client sends a transfer request with an idempotency key. The fraud service scores the request before any money moves. The transfer service writes two ledger entries in one database transaction: a debit and a credit. A database transaction is a group of writes that succeed or fail together.

Step 4: The failure path. If the fraud check times out, hold the transfer in a pending state and queue it for review. If the ledger write fails, return an error and let the client retry with the same key. The key makes the retry safe.

Step 5: Trade-offs. Discuss instant visibility against settlement delay. Discuss synchronous fraud checks against transfer speed. Discuss one database against sharded ledgers, and how sharding complicates transactions. Sharding means splitting one database into pieces by key.

How Interviewers Grade the Round

Block interviewers reward fintech specifics: idempotency, card networks, and real numbers. State a latency target and a daily volume, then design against them. Argue at least one trade-off in both directions. Storage choices matter too, and it helps to know the basic types. See file storage vs block storage vs object storage for that background.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview explains queues, databases, consistency, and caching with case studies.
• Go deeper on distributed patterns. Grokking the Advanced System Design Interview covers replication and transaction patterns that payment questions reuse.
• Practice one payment design fully. Draw the peer-to-peer system above from memory, then add fraud checks and reconciliation.
• Know the rest of the loop. Read What Is the Block Interview Process Like? (Round by Round) for the rounds around this one.
• Prepare the values conversation. Design skill alone does not pass Block. See Top Block Behavioral Interview Questions (and How to Answer Them) for the mission questions.