Practice/Apple/Design A Payment System Without Internet

Design A Payment System Without Internet

System DesignMust

Problem Statement

Design a payment system that lets people complete transactions even when neither the payer nor the merchant has internet connectivity. Think of tap-to-pay that works in airplane mode, or mobile wallets exchanging value via NFC or QR codes in areas with spotty connectivity.

The hard part is preventing fraud — specifically double-spending — without a live central authority to check balances. The system must use cryptographic techniques and local risk controls to authorize payments offline, then reconcile everything when connectivity resumes. This is a unique problem that tests your ability to design for extreme network partitions.

Key Requirements

Functional

• Offline payment -- both payer and payee can complete a transaction with immediate confirmation, even with no internet
• Local balance tracking -- the payer's device shows an accurate balance and prevents overspending beyond risk limits
• Offline validation -- merchants can verify payments using locally cached credentials and policies without calling a server
• Reconciliation -- when connectivity returns, offline transactions are settled across issuers without a single source of truth

Non-Functional

• Security -- prevent double-spending and tampering using cryptographic signatures and secure hardware
• Reliability -- transactions must survive device crashes and power loss between offline and sync
• Latency -- offline payment completion should feel instant (under 2 seconds via NFC/QR)
• Consistency -- eventual consistency is acceptable, but final settlement must be correct and auditable

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Preventing Double-Spend Without a Live Server

This is the central challenge. Without checking a central ledger in real time, how do you ensure the same digital value is not used twice?

Hints to consider:

• Issue signed, single-use tokens with unique serial numbers — the merchant records the serial locally and rejects duplicates
• Set offline spending limits (daily cap, per-transaction cap) enforced by the device's secure element
• Use short-lived spending keys that expire, limiting the damage window if a device is compromised
• When connectivity resumes, the system detects and flags any double-spend attempts for resolution

2. Cryptographic Token Design

The offline payment flow relies on tokens that are tamper-proof, verifiable without a server, and resistant to replay attacks.

Hints to consider:

• Each token is signed by the issuer's private key; the merchant verifies using the issuer's public key cached locally
• Include a nonce or serial number in each token to prevent replay
• Consider a chain of signed transactions so each spend references the previous one, making tampering detectable
• Discuss how to rotate keys and distribute revocation lists to merchants during their periodic sync windows

3. Reconciliation and Settlement

When devices come back online, potentially conflicting or fraudulent transactions need to be resolved across multiple parties.

Hints to consider:

• Use an append-only event log where each device uploads its offline transaction journal
• Apply first-writer-wins semantics: the first claim on a token serial is accepted, duplicates are flagged
• Model settlement as a saga with compensation: if a double-spend is detected, reverse or charge-back the fraudulent claim
• Discuss how to handle disputes when both parties believe they completed a valid transaction