抢购最重要的是要保证库存数据的强一致性，抢购的瞬时流量非常大，如果使用MySql等一些关系型数据库可能会扛不住这方面的压力。一般会结合缓存中间件进行处理，例如redis。抢购开始前，将商品和库存数据同步到redis中，所有的抢购操作都在redis中进行处理，后台开启一个异步任务，定时的将库存数据刷到数据库中。
跟着开始对订单进行付款，由于流量较大，第三方支付系统本身也对调用端的应用限制流量，所以你这边所说的应该是我接下来需要描述的。
这里必然要使用消息队列（也就是你所说的异步队列），可以参考淘宝双11的限流措施，为了保护系统不受高流量的冲击而导致系统崩溃的问题，消息队列做了一层缓冲保护，系统需要设计一个窗口模型，窗口模型会实时的刷新用户办理手续的状态。
例如，用户下单之后准备去付款，这个时候会跳到办事大厅的服务窗口，如果此时窗口都满了，也就是消费者的数量达到上线了，那么需要用户开始排队，系统可以通过弹出等待窗口，让用户等待一下，一旦有空闲的线程释放出来，用户就可以开始支付下单。
上面的是以拍下减库存的模型进行说明，如果你们设计的系统是付款减库存，稍微会有些出入，但是同样也需要这样的窗口需要告知用户状态，及时用户付款成功，虽然没及时把状态返回给用户，用户能够通过一个页面及时查看到他的窗口状态就可以了。

client端用js轮询一个接口，用来获取处理状态