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

SeniorPrefer not to say

May 2026

Summary

System design round at DoorDash for a software engineer role. The whole session was basically one big question about querying dasher order history at scale, and it went in a lot of directions fast.

Questions Asked (1)

Design a system to support querying completed order records across all dashers. Walk through storage choices, partitioning, indexing, pagination, async exports, freshness trade-offs, and access control.

System DesignTechnical Trade-offsData Modeling

Author's notes

This is one of those questions that looks like a single question but is really like six questions stapled together.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements: query patterns, data volume, freshness needs, and access control. Then propose a storage and partitioning strategy that balances scalability and query performance, and discuss trade-offs for each component.

Pro tip: Emphasize that freshness requirements drive the architecture: if near-real-time is needed, consider a streaming pipeline to a queryable store; if not, batch processing is simpler and more cost-effective.

1. Clarify Requirements

Ask about query patterns (by dasher, time range, order status), data volume, freshness expectations, and access control needs. This shapes all subsequent design decisions.

2. Choose Storage and Partitioning

Select a storage system (e.g., columnar store like Redshift/BigQuery for analytics, or NoSQL like Cassandra for high-throughput writes). Partition by time (e.g., daily) and optionally by dasher ID to distribute load.

3. Design Indexing and Pagination

Create indexes on frequently queried fields (dasher_id, completed_at, order_id). For pagination, use keyset pagination (e.g., WHERE completed_at < last_seen) to avoid deep offset performance issues.

4. Implement Async Exports and Freshness Trade-offs

For large exports, use asynchronous jobs that write to object storage (e.g., S3) and notify via email or webhook. Discuss freshness: streaming (low latency, higher cost) vs. batch (higher latency, lower cost).

5. Enforce Access Control

Implement role-based access control (RBAC) at the API layer, ensuring dashers can only query their own orders, while admins have broader access. Use row-level security in the database if supported.

Key Points to Mention

Partitioning strategy: time-based partitioning for efficient range queries and data lifecycle management.
Indexing: composite indexes on (dasher_id, completed_at) for common query patterns.
Pagination: keyset pagination to avoid performance degradation with large offsets.
Async exports: decouple export generation from request-response cycle, use job queues and object storage.
Freshness trade-offs: streaming vs. batch processing, and their impact on latency, cost, and complexity.
Access control: RBAC and row-level security to ensure dashers only access their own data.

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