OfferForge 导师 Dr. W. — 博士毕业，前 FAANG Senior MLE。研究方向为大规模分布式机器学习系统，曾在顶级国际学术会议发表多篇论文。负责团队学术方向把控与 MLE 面试辅导。
OfferForge 导师 Dr. S. — 前大厂 Senior SDE，精通分布式系统与大规模数据处理。曾在顶级技术会议发表多篇技术报告，专注于系统可扩展性与可靠性。负责课程体系设计与 System Design 面试辅导。
OfferForge 导师 Dr. L. — 前大厂 Senior SDE，深耕分布式系统与微服务架构。在服务治理、事件驱动架构方面有丰富实战经验。负责求职策略制定与 SDE 面试辅导，已帮助多位候选人斩获 Senior 级别 Offer。
众所周知，Stripe OA确实有点东西。这次讨论的 Stripe HackerRank OA 真题是一道非常高频的系统模拟题，背景来源于 Jupyter load balancing 的实际工程场景。Stripe 的 Notebook 平台运行在 Jupyter 上，而 Jupyter 在面对大量用户时性能下降明显，因此公司会部署多个 Jupyter servers，并通过一个 load balancer 自动分配用户请求。这道题的目标是模拟这一逻辑，实现一个函数 route_requests()，用于确定每个 incoming request 应该被路由到哪个目标服务器。虽然题目不涉及真实的网络通信，但它要求完整模拟连接建立、断开、对象共享、capacity 限制以及 server 重启等一系列复杂的行为。虽然说是一小时完成一道题，但是难度远大于tiktok的一小时四道题。
函数 route_requests(numTargets, maxConnectionsPerTarget, requests) 接收三个参数，分别代表 number of target servers、maximum connections per server、以及 request sequence。每个请求字符串格式可能为 action, connectionId, userId, objectId 或 action, targetIndex。返回值是一个字符串数组，包含所有成功的 CONNECT 操作结果，格式为 connectionId, userId, targetIndex。题目共分五个阶段（Part 1–5）每个阶段在前一阶段的逻辑上递进，最终形成一个接近真实系统负载均衡器的完整模拟。
第一部分是 Basic Load Balancing。这一阶段要求实现最基本的调度逻辑。程序需要维护每台 server 当前的 active connection 数量，当有新的 CONNECT 请求到达时，应选择负载最小的 server。如果有多个负载相同，则选择 index 最小的一个。每个请求独立处理，与用户或对象无关。核心思路是通过一个 array 或 dictionary 跟踪当前各 server 的连接数量，并在 O(1) 时间内找到最优目标。
第二部分是 Modeling Disconnection。在第一阶段的基础上新增 DISCONNECT 请求。系统需要维护一个 connection mapping table，记录每个 connectionId 当前所在的 server。当接收到断开请求时，从 mapping 中查找该 connectionId，释放相应的 server 负载。这要求在数据结构层面保持 connection 与 server 状态同步，以确保负载统计正确。实现的重点在于使 connect 与 disconnect 操作的更新成本都保持常数级别。
第三部分是 Routing Based on Object ID。这一阶段引入了对象一致性（object-level consistency）的约束。Jupyter notebooks 的多个用户可能共享同一个 objectId（即共同编辑同一个文档），因此这些请求必须被路由到同一台 server。程序需要维护一个 objectId → targetIndex 的映射表，当有新请求到达时，如果 objectId 已经存在，就直接使用同一台 server；否则执行常规的负载均衡逻辑。难点在于维护 object-server 绑定关系的正确性，并在连接断开后及时清理。