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

Intermediate

May 2026

Summary

System design round at DoorDash for a software engineer role. The question was pretty focused on a food rating and comment system, with a lot of emphasis on schema design and preventing duplicate actions like double-tipping.

Questions Asked (1)

Design a food rating system that supports average ratings, user comments, and upvotes/downvotes on comments. If a comment gets enough upvotes, the system should automatically tip the comment author. How do you design the database schema, enforce that a user can only upvote or tip once, and handle eventual consistency?

System DesignData ModelingTechnical Trade-offs

Author's notes

The idempotency part is where I got stuck.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then design a normalized schema for users, restaurants, ratings, comments, and votes, with a separate ledger for tips. Address idempotency and uniqueness constraints for votes/tips, and discuss eventual consistency trade-offs between services (e.g., rating aggregation, tip triggering) using queues and idempotent consumers.

Pro tip: Emphasize idempotency and exactly-once semantics for financial actions (tips) using unique constraints and idempotency keys, and mention how you'd handle race conditions with optimistic locking or conditional writes.

1. Clarify Requirements and Scale

Ask about expected read/write volumes, consistency needs (e.g., can ratings be stale?), and business rules (e.g., upvote threshold for tipping). This shapes the design.

2. Design Core Schema

Propose tables: users, restaurants, ratings (user_id, restaurant_id, rating), comments (id, user_id, restaurant_id, text, upvotes, downvotes), votes (user_id, comment_id, vote_type), and tips (id, user_id, comment_id, amount, status). Include unique constraints on (user_id, comment_id) for votes and tips.

3. Enforce Uniqueness and Idempotency

Use database unique constraints to prevent duplicate votes/tips. For distributed systems, use idempotency keys and conditional writes (e.g., INSERT ... ON CONFLICT DO NOTHING) to handle retries.

4. Handle Eventual Consistency

Decouple rating aggregation and tip triggering via message queues. Use idempotent consumers, deduplication, and compensating transactions. Discuss trade-offs: eventual consistency for ratings vs. strong consistency for tips.

5. Address Scalability and Trade-offs

Discuss sharding by restaurant_id or user_id, caching hot data, and using a ledger for tips. Mention monitoring and reconciliation for consistency.

Key Points to Mention

Unique constraints on (user_id, comment_id) for votes and tips to enforce one vote/tip per user.
Idempotency keys and conditional writes to handle retries and prevent duplicate tips.
Eventual consistency via message queues (e.g., Kafka) for rating aggregation and tip triggering.
Idempotent consumers and deduplication to ensure exactly-once processing.
Trade-offs between strong consistency (for tips) and eventual consistency (for ratings).
Use of a ledger table for tips to ensure auditability and financial correctness.

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