订单支付系统是大型架构核心，下面我详解订单支付系统TPS@mikechen
订单支付系统
订单支付系统，往往涉及下单、风控、库存校验、第三方支付、账务记账、回调通知等多个环节。
任何一个环节的延迟、或失败都可能影响用户体验、和资金安全。
因此，即便TPS看似不算特别夸张，也可能已经属于高并发系统。
TPS多少算高并发
如果专门看订单支付系统，可以用下面这个比较实用的工程口径：
|
系统类型
|
日常/常规 TPS
|
算“高并发”的门槛
|
说明
|
|---|---|---|---|
|
中小型电商/本地生活
|
200–500
|
≥ 1,500–2,000
|
促销、周末高峰常见
|
|
金融支付/第三方支付接口
|
100–500（或 500–1,200）
|
≥ 1,000–3,000
|
更看重稳定性和一致性
|
|
中大型电商平台
|
1,000–数万
|
≥ 5,000–10,000+
|
需要分布式架构支撑
|
|
头部平台（支付宝等）
|
日常已很高
|
数万～数十万甚至更高
|
双11峰值可达 25万–58万+ 笔/秒
|
1,000–3,000 TPS：对大多数中小型订单支付系统来说，已经算高并发，需要认真做架构优化（缓存、异步、限流、分库分表等）。
≥ 5,000 TPS：普遍被认为是“高并发”门槛，单机或简单集群很难稳定支撑，通常需要分布式、消息队列削峰、单元化等设计。
≥ 1万–数万 TPS：大型电商/支付平台的常态峰值水平。
10万+ TPS：超高并发（如支付宝双11、微信春节红包等场景）。