DoorDash·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

May 2026

Summary

System design round at DoorDash focused on payment infrastructure, specifically a deep dive into storage layer decisions. The question was deceptively broad and I felt like I was playing catch-up the whole time trying to cover enough ground without going too shallow on any one piece.

Questions Asked (1)

You're designing a payment system. For each component, which database would you choose and why? Walk through the trade-offs across relational stores, caches, document stores, wide-column databases, and append-only ledgers.

System DesignTechnical Trade-offsData Modeling

Author's notes

This felt like five questions duct-taped together.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the payment system's requirements (e.g., consistency, latency, throughput, auditability) and then map each component (transaction processing, user profiles, session data, analytics, ledger) to the most suitable database type. For each choice, explain the trade-offs in terms of consistency, scalability, and complexity, and justify why alternatives are less appropriate.

Pro tip: Emphasize that payment systems prioritize correctness and auditability over raw performance; for example, using an append-only ledger for financial records ensures immutability and simplifies reconciliation, even if it means higher storage costs.

1. Clarify Requirements

Ask about expected scale, consistency needs, latency requirements, and regulatory constraints to tailor your database choices.

2. Map Components to Databases

Identify key components (e.g., transaction processing, user data, session management, analytics, ledger) and propose a database type for each based on its access patterns and consistency needs.

3. Explain Trade-offs

For each choice, discuss trade-offs: relational (strong consistency, complex scaling), cache (low latency, volatile), document (flexible schema, eventual consistency), wide-column (high write throughput, limited query flexibility), append-only ledger (immutable audit trail, storage overhead).

4. Justify with Examples

Provide concrete examples from DoorDash's context, such as using a relational database for payment transactions to ensure ACID, Redis for session caching, and a ledger for financial auditing.

5. Summarize and Conclude

Recap how the chosen databases collectively meet the system's requirements, highlighting the balance between consistency, availability, and performance.

Key Points to Mention

ACID compliance in relational databases for transaction integrity
Eventual consistency and low-latency access with caches like Redis
Flexible schema and horizontal scaling of document stores (e.g., MongoDB) for user profiles
High write throughput and scalability of wide-column stores (e.g., Cassandra) for analytics or logging
Immutability and auditability of append-only ledgers (e.g., blockchain or event sourcing) for financial records
Trade-offs between consistency, availability, partition tolerance (CAP theorem) and latency

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.