处理大量支付的常见架构(例如，如果你是一个送餐应用程序(是一个带有某种分布式消息的pub/sub架构，例如Kafka。消费者随后致电第三方支付处理器。通常情况下，第三方支付处理器可能会超时或停机，因此需要额外的设置来处理重试。DB通常也用于跟踪支付状态，例如让额外的消费者在DB中设置记录。我很难理解的一个问题是，如果出现合法错误，例如卡的详细信息不正确，如何及时将此错误返回给用户？我们可能不想立即给用户一个成功消息，然后再给他们一个错误？
支付流应该是强一致的，用户需要知道(在离开页面之前(是否发生了支付。关于如何实现这一点，我可以想到两种方法：
- 如果你有一个事件驱动的架构，你可以为支付请求/响应创建专用队列，并确保瓶颈在第三方支付处理器中，而不是在你的系统中。前端可以轮询结果(当然是以异步方式(，并一致地通知用户付款状态
- 如果可行的话，您可以使用HTTP/gRPC中已经设计好的请求-响应模型，上面提到的方法基本上做了同样的事情，但在事件驱动的世界中。因此，API网关没有将消息放在队列中，而是直接调用支付微服务