很多时候，一提到交易系统，大家首先想到的都是性能，比如撮合速度、延迟和吞吐量。这些当然很重要，但这次内部讨论让我感觉，真正值得反复琢磨的，未必只有“快”这一件事。
When people talk about trading systems, performance is usually the first thing that comes to mind: matching speed, latency, and throughput. Those things are certainly important. But this internal discussion made me feel that speed is not the only topic worth revisiting again and again.
On March 9, the discussion moved the project toward a more unified architectural direction. Instead of continuing to think in terms of multiple Lyquid instances with pre-assigned responsibilities, the team aligned on a single-Lyquid design that could host multiple roles while sharing the same underlying state. That shift matters because it changes both the technical implementation path and the way different features, especially matching and index-price-related logic, are expected to coexist.
This diagram reflects the architecture concept discussed on February 27. See the earlier post here.
On February 27, the discussion combined three layers of the project that are usually hard to keep aligned at the same time: contract execution, day-to-day delivery discipline, and the longer-term system architecture. The result was a more grounded view of what had already been validated, where execution was slipping, and which architectural questions still needed sharper answers.
The February 22 discussion narrowed the project down to a practical migration sequence: validate the current system in a realistic environment first, then move service by service toward Lyquid without breaking the existing operational model. The emphasis was not on a big architectural rewrite, but on establishing a baseline, preserving comparability, and reducing uncertainty as each layer is adapted.