PayPal System Design Interview Questions

Yes. They’re challenging and comparable to those at Google or Amazon, focusing heavily on secure, scalable financial systems.

Start with System Design fundamentals, especially for financial systems. Practice common scenarios and review PayPal’s engineering blog for real-world insights.

Common mistakes include neglecting security, skipping scalability trade-offs, overlooking financial reliability, and jumping into solutions without clarifying requirements first.

A payment gateway needs to authorize, route, and settle payments securely and efficiently. When a customer initiates a transaction, the system should validate card details, encrypt the data (e.g., using TLS and tokenization), and route it to the correct payment processor or acquiring bank. You need to handle retries, 3DSecure challenges, and eventual settlement. Latency and uptime are critical here—every second counts for conversion rates. You’ll also need fraud hooks and logging for compliance.

A digital wallet securely stores users’ payment methods (cards, bank accounts, balance) and enables transactions across devices. The key design goals are security, ease of access, and real-time updates. You’d use tokenization for stored credentials, enforce 2FA, and encrypt all data at rest and in transit. Balances must sync instantly across devices, and any change—like adding a card or receiving money—should trigger event-driven updates to the wallet state.

Fraud detection is about balancing accuracy, latency, and adaptability. Every transaction is scored in real time based on user behavior, location, device fingerprinting, transaction history, and more. Use a rule engine (for fast decisions) plus a machine learning layer (for pattern recognition). You’ll need a feedback loop to retrain models from false positives/negatives. For scale, stream processing (e.g., Kafka + Flink) helps handle real-time scoring and async reviews.

Payment processing must be ACID-compliant, highly available, and resilient to failure. Break the process into steps: authorization, capture, settlement, and reconciliation. Each step should be idempotent and retry-safe. Use a distributed transaction model like the Saga pattern to manage long-lived workflows. Store transactions in a write-optimized database, with change events triggering downstream processing. And always log everything—for audits, disputes, and rollbacks.

P2P systems must prioritize instant transfers, trust, and social context. Each transaction involves balance checks, fraud scanning, and optional payment messages. Funds can move between internal wallets instantly and settle with banks later. You’ll need a strong user identity model (phone/email-based) and a way to resolve disputes. It’s also smart to support emoji, comments, and social feed-style notifications to mimic the PayPal experience.

Multi-currency support means handling currency conversion, regulatory differences, and exchange rate volatility. You’ll need a forex service to fetch real-time rates, apply margins, and display the correct amounts to users pre-conversion. Ledger entries must preserve original and converted values. Be careful about rounding, double-entry bookkeeping, and compliance with currency-specific rules (e.g., tax handling in the EU). And yes, users expect full transparency in fees.

This system must support flexible plans, retries, and lifecycle management. Store subscription metadata (frequency, amount, start/end dates) and schedule billing events. Use a job scheduler or event queue to trigger payment attempts. Add retry logic with exponential backoff, dunning emails for failed payments, and graceful handling of plan upgrades/downgrades. Proration, tax, and invoice generation all play a part too. Most importantly: make cancellations easy but reversible.

Security here is non-negotiable. Start with email/phone-based login, salted password hashing (e.g., bcrypt), and rate limiting. Add optional 2FA (via SMS or authenticator app). For session management, use signed tokens (JWT or opaque tokens + session store) with short lifetimes. Consider device binding and risk-based authentication—e.g., challenge login if a new device/location is detected. Also, support OAuth for third-party integrations, but never expose sensitive scopes without user consent.

You need a pipeline that can ingest, store, and analyze billions of transaction events. Use a message broker like Kafka to stream raw events into both hot and cold storage—e.g., a real-time store (Elasticsearch) for dashboards, and a data lake (S3 + Hive/Presto) for historical queries. Add a metadata index to support advanced filters (user, amount range, status). Build APIs for product teams and dashboards for ops, with strict access control due to PII and financial data.

This system needs to be reliable, fast, and alert-driven. Aggregate logs from all services using agents like Fluentd or Logstash. Route them to a log processor (e.g., Elasticsearch) for querying and retention. Metrics (latency, error rate, volume) go to a TSDB like Prometheus, with Grafana dashboards and alerting rules. Design it to handle log spikes (e.g., Black Friday traffic) and ensure no log loss—logs are often your only defense during incidents or audits.

A flight booking platform needs to handle inventory, pricing, search, and payment workflows. Start with a real-time availability engine that syncs with airline GDSs. Add a search API with filtering and ranking logic. Pricing must reflect dynamic fares and include tax/fee calculations. Once the user selects a flight, holds the seat (lock inventory), initiates payment, and confirms the booking with the airline. Don’t forget cancellation, refund, and itinerary change workflows, all of which are pain points if not automated.