话务系统平台是典型的LNMP架构，架设在AWS云服务上，前端使用AWS ELB作为负载均衡，为业务方和供应商提供接入口，流量分发到后端多台Server上，Server可以很方便地水平扩展。ELB和Server之间有TCP健康检查。
存储采用MySQL，呼叫中心外呼系统用以保存号码绑定关系、会话关系、可分配号码号池，以及通话记录。通话记录历史数据会定期归档。旁路有一个控制台UI，用来做数据报表展示，以及控制号池调度。客户究竟是怎样通过拨打虚拟号联系到经纪人的呢？
1. 绑定。首先客户要拿到被叫经纪人的虚拟号。客户访问业务线产品，业务线产品调用话务平台绑定接口，传递经纪人真实号，话务平台从号池中取出一个储备虚拟号，建立绑定关系，并将虚拟号返回给业务线产品。在这里，绑号接口同时也是查询虚号接口，如果真实号已经有绑定关系，则直接返回已绑定虚号，如果尚未绑定，则绑定后再返回虚号。虚拟号是按需分配，并非所有经纪人都预先分配一遍，这样可以节约号码。
2. 拨打。客户拨打虚号，或者通过APP自动调用号盘拨号。通话流程转到运营商，运营商再将通话流程转到与之有合作关系的供应商，可以理解为供应商在运营商处注册了路由。因为拨打的是虚号，而虚号的绑定关系存储在话务平台，故供应商调用话务平台查询虚号的绑定关系。
3. 转接。供应商通过话务平台接口查到虚号对应的真实号，然后做转呼。双方建立通话。电话销售呼叫系统，在这里，供应商可能查到多个真实号，按照约定，供应商按顺序逐个转呼真实号，直到某一个接通或者都未接通。每次转呼有一定的超时时间，这样既保证用户不用等太久，又避免经纪人漏接电话。
4. 推送话单。当通话结束之后，供应商将话单数据推送至话务系统平台，话单包含号码、时长、计费、通话状态等关键信息。话务平台存储话单，并推送给业务方。在这里，可能受到网络抖动等因素影响而推不成功，我们的解决方案是：
A、供应商重复推送，当出现超时、503等状况时，供应商标记该条话单为“未同步成功”状态，并在一定时间后重新发起推送，如果仍然不成功，则拉长时间间隔后再次推送；
B、话务平台定期拉取话单，和本地数据check，若发现丢单则补单。
以上通过重复推送和推拉结合的方式保证话单数据及时、正确地同步。这一设计在其他数据同步的设计中已被证明为一种行之有效的方法，比如支付行业，第三方支付平台通知商户支付订单状态就是采用这种方法。
