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

SeniorPrefer not to say

May 2026

Summary

Stripe system design round that extended a worker-task-assignment problem across multiple parts, with this one adding account-based sticky routing on top of the existing type-aware scheduling logic. Genuinely tricky because the edge cases compound fast and the interviewer wanted you to reason through all of them out loud.

Questions Asked (1)

You have a worker-task-assignment system where each task now carries an account field. Tasks from the same account should always route to the same worker (sticky routing), unless that worker doesn't support the task's type, in which case you fall back to the earliest-free eligible worker. Design this system, discuss the data structures needed, and walk through a sample stream of tasks.

System DesignAlgorithms & Data StructuresTechnical Trade-offs

Author's notes

This one built on two prior parts so by the time we got here I thought I had a handle on it.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then propose a design that combines a sticky mapping (account to worker) with an eligibility check and a fallback mechanism. Walk through the data structures and a sample stream to demonstrate correctness and efficiency, and discuss trade-offs like consistency and scalability.

Pro tip: Emphasize the importance of handling worker unavailability and reassignment gracefully—mention how you'd detect failures and update the sticky mapping to maintain correctness. Also, discuss how to avoid hotspots by considering load balancing in the fallback.

1. Clarify requirements and assumptions

Ask about worker capabilities (task types supported), definition of 'earliest-free', persistence requirements, and scale (number of accounts, tasks, workers). Confirm whether sticky routing is strict or best-effort.

2. Design core data structures

Propose a hash map from account ID to worker ID for sticky routing, a map from worker ID to supported task types, and a priority queue or sorted structure to track worker availability for fallback.

3. Define routing algorithm

For each task, check if the account has a sticky worker; if that worker supports the task type and is available, assign. Otherwise, find the earliest-free eligible worker from the fallback structure and update the sticky mapping.

4. Walk through a sample stream

Simulate a sequence of tasks from different accounts, showing how assignments are made, how fallback triggers when a worker is busy or ineligible, and how the sticky mapping updates.

5. Discuss trade-offs and extensions

Cover consistency (e.g., handling worker failures), scalability (sharding by account), and potential improvements like load-aware fallback or TTL for sticky mappings.

Key Points to Mention

Sticky mapping using a hash map (account -> worker) for O(1) lookup.
Worker eligibility check via a map of worker capabilities (worker -> set of task types).
Fallback mechanism using a priority queue or min-heap of free workers ordered by availability time.
Handling worker unavailability: detect failures and reassign tasks, updating the sticky mapping.
Trade-offs: strict vs. best-effort stickiness, consistency vs. availability, and scalability considerations.
Sample stream walkthrough to illustrate the algorithm in action.

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