当客户在线购物时，每一秒都至关重要。研究表明，页面加载速度直接影响转化率：加载2.4秒的页面转化率为1.9%，而加载5.7秒或更长的页面转化率仅为0.6%。尤其在黑色星期五/网络星期一等高峰期，您绝不希望客户因加载缓慢而放弃购买。
TaxJar 高度重视速度。平均而言，我们的销售税计算 API 端点比最接近的竞争对手快16倍以上，欢迎在状态页面上亲自验证。
销售税计算还必须准确可靠。作为商家，销售税 API 至关重要；若服务宕机导致无法向客户收取税款，报税时您将需自掏腰包支付这笔费用。
我们保证99.99%的正常运行时间，并提供备用税率以防万一。相比之下，竞争对手承诺的最低服务可用性仅为99.5%。
每年停机超过1天是不可接受的。结合较高的响应时间，仅销售税 API 问题就可能每年导致数万美元的收入损失。
TaxJar 的 API 从 Ruby 迁移到 Elixir
2018年，工程团队做出战略决定，开始将 Ruby API 端点迁移至 Elixir。截至2019年8月，100%的销售税计算已在工业级、高性能且完全分布式的 Erlang VM 上运行。
Elixir 是一种函数式并发编程语言，使我们能够充分利用 Erlang 的可扩展性。WhatsApp 使用 Erlang 在单节点上支持超两百万并发用户，AdRoll 每秒处理超50万次竞价请求。TaxJar 则利用 Erlang 每月为整个平台及财富500强公司执行数亿次销售税计算，同时大幅降低了 AWS 服务器成本。
TaxJar 采用金丝雀发布策略，通过将部分流量导向新的 Elixir 端点，剩余流量经 Amazon API Gateway 导向旧版 Ruby 端点来实现平滑过渡。随着对 Elixir 调用的逐步增加，我们最终有信心在生产环境中使用 Elixir 处理100%的 API 请求。
为确保万无一失，我们设计了名为 Kodan 的内部项目，通过新 Elixir API 重放数百万条历史请求，并使用 Amazon Athena 进行分析。这帮助我们发现了可能导致与 Ruby API 行为差异的边缘情况和意外场景，确保两者在处理传入请求时完全一致，从而在影响生产环境用户前捕捉并解决这些差异。
保持 API 间请求处理的一致性带来了一些挑战。例如，需在 Elixir 中复制 Ruby 宽松的类型系统（如 `“”.to_f == 0` 等隐式转换），以及镜像 Ruby 的排序行为，以确保响应中行项目和其他数据集合的顺序保持一致。
总体而言，从 Ruby 到 Elixir 的过渡非常顺利。虽然编写函数式代码需要思维转变，但这极大简化了测试工作。Elixir 的函数式特性允许进行微小且隔离的代码更改，让我们确信不会影响代码库其他区域。模式匹配帮助我们在复杂的验证层中编写出比 Ruby 条件语句更清晰的代码，而 `with` 语句、协议和 Behaviours 等底层语言特性也显著提高了生产力。
得益于从 Ruby 切换到 Elixir，我们的平均响应时间从 75ms 降至 18ms，基础设施和服务器成本也大幅降低。即便面对黑色星期五和网络星期一的流量高峰，API 依然游刃有余。TaxJar 的 API 专为持久运行而构建，旨在为整个电子商务平台和市场提供强劲动力。