我们从零开发了一个交易平台。以下是我们的真实投入。

图表和报价看起来是简单的部分，实际上却是整套系统中最难的运营问题，因为市场数据并不是单一的产品。加密货币报价可以从交易所接口免费获取。外汇根本没有集中的成交记录，因此零售平台依赖交易商数据源和非官方接口。股票数据需要授权，按交易所定价，而价格能负担得起的套餐不包括相邻的资产类别。

我们试过免费、无需密钥的接口，非官方的图表数据源，以及数据供应商的免费套餐，每一种都以各自的方式失败了：有的屏蔽来自云数据中心地址的请求，有的在免费套餐中不返回任何外汇数据，有的没有货币对的成交量数据，因为真正的现货外汇根本没有成交量可报。每个数据源出问题的方式都不同，而交易产品必须在这一切情况下保持报价不断。

最终，我们建立了自己的专用数据服务，使用持牌商业数据，配备独立的故障切换，并作为基础设施来运营。市场数据是一个需要您持续运营的产品。无论自主开发还是购买，都请按这种思路做预算。

价格图表晚一秒渲染只是让人恼火，一笔入金被重复入账则是一起事故。演示版和真正平台之间最大的区别在于：资金经过的每一条路径，都按照与其他一切不同的标准来设计。

具体来说，这意味着结算逻辑即使运行两次也不会重复入账，因为在分布式系统中，事情就是会运行两次。这意味着银行电汇从不自动入账，因为看似已到账的电汇和已清算的电汇是两回事。这意味着交易只能以数据源中真实存在的价格成交，绝不能以过时或插值得出的价格成交，因为以从未成交过的价格成交会引发纠纷。这还意味着每一项这样的决定都会留下审计记录，因为受监管的企业总有一天会被要求出示。

这些都是常规的工程工作，只是每一次都要严格执行。这也是小团队在上线压力下最想推迟的部分，而且一旦发生第一起真实客户事故，就无法再事后补救。

无服务器托管很适合网站，却不适合交易系统。函数在两次请求之间就不复存在，无法承载后台进程，因此任何持续性的工作，从报价分发到跟单交易执行，都必须改写为轮询和队列。长时间的流式连接会碰到硬性超时。持久化状态必须保存在数据库中，因为文件系统在两次调用之间不会保留。

这些教训我们都是吃过苦头才学到的，架构也因此变得更好：习惯性地保持幂等，处处可恢复，运行成本低廉。但这些经验花了数月的工程时间，而为自主开发做预算的创始人根本想不到要把这部分算进去，因为在您真正碰到之前，没有哪张架构图会显示出这种限制。

白标听起来像是一项样式工作，直到您尝试把它贯穿整个产品。真正属于经纪商自己的品牌，必须覆盖交易终端、CRM、邮件、应用图标和域名，而经纪商的数据必须保存在其自己的数据库中。我们把品牌和部署做成了配置，由同一套代码生成完全独立的品牌部署，因为另一种做法，即为每个客户分叉一份代码，会让今后的每一次修复都变成乘以客户数量的工作量。

销售演示不会展示这个决定，但它会影响平台很多年。这也是我们建议创始人向每家供应商提出的“一个数据库”之问的由来：您的客户数据存放在谁的数据表里？

成本没有单一的数字。第一个可用版本需要数月的全职工程投入。能让受监管企业运营的版本则要数倍于此，因为两者之间的差距正是上文描述的那些不起眼的工作：数据韧性、资金路径的严谨性、可审计性和品牌隔离。而且这笔开支永无止境，因为市场在不断变化，交易平台必须持续维护。

这就是自主开发与购买之间的抉择的关键所在。当自有技术本身就是业务时，自主开发是正确的选择。对于优势在于渠道、服务或细分市场的经纪商来说，自主开发是一条昂贵的弯路，要重新解决早已被解决的问题。我们之所以这么说，是因为我们自己走过这条弯路，这也是这个平台存在的原因：让下一位创始人不必再走。