/英高并发从一次 Agoda 系统设计面试的收获

高并发：从一次 Agoda 系统设计面试中的收获

分享一个我在应聘 Senior Full Stack Engineer 职位时的面试经历。由于我的英语口语有限，这次面试对我来说是一次相当大的挑战。下面也提供了英文版，主要是为了练习英文。中文版为英文版翻译过来，味道可能会怪一些，见谅。

当我走进面试室的时候，我就意识到这是一次具有挑战性的机会。这是第二轮面试。

在我参与 Agoda 高级全栈职位的面试过程中，我充分意识到前方的道路将是严峻而复杂的。这个职位对前端和后端技术的深度和广度强调非常重要，意味着面试过程自然会在复杂性和设计期望方面逐渐提升。

但重要的是，我的英语口语表现不够出色，这让我失去了这个职位的机会。下一步需要不仅仅是磨练我的技术，还需要集中精力提升我的沟通能力和软性技能。

面试流程

任务 1： 这是一个相对简单的前端任务，主要涉及 React 的基础知识，包括 useState、useEffect 和防抖。我认为这个任务对我来说相对轻松。

任务 2： 高并发系统设计：如何展示和存储用户数量？特别是在同时有 100 万用户和 20 万用户访问产品详情页面的情况下。如何设计前后端来在详情页面中显示这个数字。

在我面对这个问题时，我意识到设计一个处理如此高并发的系统是一个复杂的任务，需要对各个方面进行仔细的考虑。

因此，我从两个方面提出了以下解决方案：

1. 前端：

在前端，关键是为用户提供关于当前浏览产品详情页面人数的实时更新。为了实现这一点，我提出了两种策略：

• CDN 静态资源： 将所有资源放在 CDN 中，如 js、css、图像等。这可以减轻服务器的压力，提高用户体验。如果我们想要减小资源的大小，还可以使用雪碧图来合并图像。但这只是提高网站性能的简单方法，不是关键点。
• WebSocket 和 SSE（服务器推送事件）： 将 http 协议直接升级为 ws 协议。通过实现 ws 协议或 SSE 连接来实现前端和后端之间的实时通信。这确保用户在用户计数发生变化时立即收到更新。

2. 后端：

后端是处理用户计数和有效提供实时数据的核心。为了应对高并发挑战，我提出了以下策略：

• 负载均衡和 API 网关： 使用负载均衡器和 API 网关将传入的流量分发到多个服务器和后端实例。这确保后端可以处理高数量的请求并高效地提供服务，同时避免任何单个组件成为瓶颈。
  • 在 API 网关中设置速率限制，以防止后端被过多的请求压倒。我认为这可以保持后端的稳定性。
• 微服务架构
  • 缓存机制： 集成内存缓存机制以存储用户计数，比如使用 Redis，可以快速高效地检索计数数据。这可以减轻数据库的负担并提高响应时间。
  • 在与一位朋友讨论后，我了解到 Redis 还支持持久性机制，例如追加日志文件（AOF）和 Redis 数据库（RDB）快照。在服务器故障的情况下，我们可以通过读取日志文件来恢复数据。
  • 历史数据的数据库： 直接使用数据库存储历史用户计数数据，以便进行分析并深入了解用户行为趋势。
  • Restful API MQ： 使用 Restful API 和消息队列（MQ）的组合来处理前端请求，与后端服务进行有效的交互，并确保广播更新的异步通信。这种方法有助于处理高并发和大量请求。它还允许在处理请求时进行可扩展性和灵活性。实际上，这是用户计数。
  • RPC ProtoBuf： 使用 RPC ProtoBuf 在微服务之间进行通信。但在面试过程中，我忘记了ProtoBuf的确切名称，最终只是将其描述为二进制缓冲协议。我认为这是一个严重的错误。设置临时数据库来存储 ProtoBuf 数据，同时添加一个标志状态变量来指示是否准备就绪以供消费，或者数据是否已经被消耗，可以增强数据的一致性，并有助于有效管理数据流。在 RPC 的上下文中添加标志的这种方法通常非常适用于事件驱动的架构。它支持异步通信和灵活性。标志状态特别适用于同时发生多个操作的场景。它可以表示各种状态，比如准备就绪、处理中、已消耗。

忽视的问题

总结起来，你的回答展示了一个坚实的基础，但由于没有涉及到以下关键方面，你的解决方案还不够深入。通过在解释中加入这些考虑因素，你将提供一个更全面和周到的解决方案，从而展示你解决高并发系统设计方面的复杂问题的能力。

1. 确保数据一致性和并发操作的正确性。 需要详细解释锁、事务和隔离级别等机制，以应对这些挑战，进一步强化我的论据。
2. 全面考虑负载均衡算法、缓存策略、API 设计和消息队列的选择。 详细介绍不同的负载均衡算法，讨论缓存驱逐策略，详述 RESTful API 设计原则，并比较不同的消息队列选项，将展示出更深入的系统设计细节理解。
3. 在高并发情况下管理 WebSocket 连接和资源。 没有详细阐述如何在高并发期间有效管理 WebSocket 连接和处理资源利用率。讨论连接池、限流和资源监控等技术，可以突显出处理实际挑战的能力。

总结

最终，我认为在面试中表现得不够出色。因此，我仍然需要提升我的口语表达能力。我还需要更多地学习有关系统设计的知识。我认为这是提升解决问题能力的良好途径。

High Concurrency: What I Learned from a System Design Interview with Agoda

Share an interview with Senior Full Stack Engineer. For my pool English, it's a tough time for my interviewer. I knew I was in for a challenge when I stepped into the room of the interview. It's round 2. As I embarked on the journey of interviewing for the Senior Full Stack position, I was well aware that the path ahead would be demanding and intricate. The role's emphasis on depth and breadth across both front-end and back-end technologies meant that the interview process would naturally elevate complexity and design expectations. This reflection delves into the immersive experience of my Senior Full Stack interview, offering insights into the heightened technical demands and the intricate design aspects that shaped the assessment. Navigating through this process not only tested my technical proficiency but also underscored the significance of well-rounded expertise at a senior level. But the important thing is that my spoken English is not good enough, and it cost me the offer. The next step involves not only honing my technical skills but also focusing on improving and enhancing my communication skills and soft abilities.

The Interview Process

Task 1. Just be a simple Front end task. It mainly described the basic knowledge of React, useState, useEffect, and debounce. I think it is easy for me. Task 2. High Concurrency System Design: How to display and store user counts? Especially when there are 1 million users and 200K are accessing a product detail page simultaneously. How to design the front and back end to display the number on the detail page. When I get this question, I realized that designing a system handle such as high concurrency is a multifaceted endeavor that requires careful consideration of various aspects. So I described the following steps to solve this problem from 2 aspects:

1. Front-End In the front end, the key point is to provide real-time updates to users about the number of individuals currently viewing a product detail page. To achieve this, I proposed 2 strategies:

• CDN static resources. Put all resources in CDN, such as js, CSS, images, etc. This can reduce the pressure on the server and improve the user experience. If we want to reduce the size of the resource, we also can use sprites to combine the images. But it just is a simple way to improve the performance of the website, not the key point.
• Websocket and SSE(Event-Source). Directly upgrade HTTP protocol to ws protocol. So implement ws protocol or SSE connections to facilitate real-time communication between the front and backend. It ensures users receive instant updates on user counts as they occur.

2. Back-End The backend is at the core of handling user counts and serving real-time data efficiently. To address the high concurrency challenges, I proposed the following strategies:

• Load balance and API Gateway. Utilize load balancers and an API gateway to distribute incoming traffic across multiple servers and backend instances. This ensures that the backend can handle the high volume of requests and serve them efficiently, besides preventing any single components from becoming a bottleneck.
• It looks like we could set Rate-Limiting in API Gateway to prevent the backend from being overwhelmed by too many requests. I think it could keep the backend stable.
• Microservices architect.
• Caching mechanism. Integrate an in-memory caching mechanism to store the user counts. Like Redis, it could retrieve count data quickly and efficiently. It could reduce the load on the database and enhance the response times.
• After discussing with a friend, Redis also supports persistence mechanisms. Such as Append-Only File(AOF) and Redis Database(RDB) snapshots. In the event of a server failure, we can recover data by reading the log files.
• DB for historical Data. Directly using a database to store historical user count data, allowing for analysis and insights into user behavior trends.
• Restful API MQ. Utilizing a combination of restful APIs and a message queue(MQ) to handle the front requests. Effectively interact with the backend services and ensure asynchronous communication for broadcasting updates. This approach is beneficial for handling high concurrency and large volumes of requests. And it also allows for scalability and flexibility in handling the requests. Actually, it's user counts.
• RPC ProtoBuf. Using RPC ProtoBuf to communicate between microservices. But in the period of the interview, I forget the exact name of ProtoBuf, eventually I just described it as binary buffer protocol. I think it's a big mistake. Set a temporary database to store the ProtoBuf data, along with a flag status variable to indicate the readiness of consumption or if data has already been consumed, enhances data consistently and helps manage the data flow efficiently. This method which adds a flag in the context of RPC is typically well-suited for event-driven architecture. It supports asynchronous communications and flexibility. Flag status is particularly suitable for scenarios where multiple actions occur concurrently. It can signify various states, like ready for, consumption, processing, and consumed.

Overlook

In conclusion, I have overlooked several critical considerations.

1. Ensure data consistency and concurrent operation correctness. I need to explain mechanisms such as locks, transactions, and isolation levels to address these challenges would have further strengthened my evidence.
2. Thorough Consideration of Load Balancing Algorithms, Cache Strategies, API Design, and Message Queue Selection. Addressing different load-balancing algorithms, discussing cache eviction policies, elaborating on RESTful API design principles, and comparing various message queue options would demonstrate a more comprehensive understanding of system design intricacies.
3. WebSocket Connection Management and Resource Management in High Concurrency. Not elaborate on how effectively manage WebSocket connections and handle resource utilization during periods of high concurrency. Discussing techniques like connection pooling, throttling, and resource monitoring would highlight proficiency in handling practical challenges.

Conclusion

In the end, I think I don't have a good performance in the interview. So I still need to improve my spoken English. And I also need to learn more about system design. I think it's a good way to improve my ability to solve problems.

这篇好文章是转载于：学新通技术网