{"schemaVersion":"1.0","type":"Article","types":["Article"],"slug":"building-software-that-markets-can-trust-7ylzg","url":"https://zyvop.com/building-software-that-markets-can-trust-7ylzg","title":"Building Software That Markets Can Trust","subtitle":null,"tldr":"In financial systems, availability isn’t enough. The real test is whether you can explain, reproduce and defend the result. There is a class of software where c...","keywords":[],"entities":["Matthew Hartley","Chief Engineer","ZyVOP"],"keyTakeaways":["Engineering for high-availability capital markets and pricing systems There is a class of software where correctness is not an aspiration.","A pricing platform can sit behind thousands of transactions a day, feed a dozen downstream systems, and run continuously through markets that do not pause while you deploy.","A small defect stops being a bug and becomes a financial, operational or reputational event."],"headings":["Correctness has more than one dimension","A pricing system is trustworthy when it can be replayed","Determinism is a feature","Performance is about the tail","Operational simplicity compounds","Build for investigation, not just execution","Six principles","Trust is an architectural property"],"outboundLinks":[],"contentText":"Engineering for high-availability capital markets and pricing systems There is a class of software where correctness is not an aspiration. It is the product. A pricing platform can sit behind thousands of transactions a day, feed a dozen downstream systems, and run continuously through markets that do not pause while you deploy. A small defect stops being a bug and becomes a financial, operational or reputational event. The engineering problem is therefore not making the software fast. It is making its behaviour predictable under pressure. Correctness has more than one dimension For a pricing system, returning the mathematically right number is the easy half. The system also has to answer whether the correct market data was used, whether that data was current, which version of the model was applied, whether the result can be reproduced tomorrow, what happened when an upstream dependency failed, and why the number changed since the last time somebody looked. That makes observability part of correctness, not an operational add-on. If a result cannot be explained after the fact, the system is not operationally correct even when the calculation was sound. A number nobody can defend is a number the business cannot use. A pricing system is trustworthy when it can be replayed There is a single test that subsumes most of the others. Can an engineer reconstruct not only what number the system produced, but why it produced that number rather than a different one? Replay is demanding, and that is the point. Every input that influenced the result has to become explicit, recorded and versioned. A system you can replay is one where the market data snapshot is addressable, the model version is pinned, the configuration is versioned, the ordering of events is preserved, and time entered through a declared dependency rather than a call to the system clock buried three layers down. Systems that cannot be replayed fail in a characteristic way. The number was wrong, nobody can say why, and the investigation becomes an argument between people reading logs that were never designed to answer the question. Systems that can be replayed turn that argument into a command. Replay is also the honest way to test a change. Running a new model version across a recorded period and diffing the outputs tells you what actually changed. A test suite tells you what you thought to ask. Determinism is a feature Given the same inputs, a system should produce the same result. That sounds too obvious to state until distributed services, asynchronous messaging, streaming market data and mutable configuration are all in the picture, at which point it becomes an active engineering goal rather than a default. Engineering for determinism means making the important inputs explicit and traceable. Version the configuration. Record the inputs alongside the outputs. Control ordering where ordering carries meaning, and separate calculation from side effects so the calculation can be re-run in isolation. Make time an explicit dependency instead of letting it leak in through a dozen calls to the system clock, because a system that reads the wall clock in fifteen places cannot be replayed. None of this is free, and all of it pays for itself the first time a result has to be reconstructed months after it was produced. Failure is part of the design A system that only holds up while everything around it holds up is relying on luck. A capital-markets platform needs designed answers to the obvious hard questions: what happens when market data stops arriving, when a downstream service is unavailable, when messages arrive late or out of order, when a deployment introduces a defect, and when an operator needs to stop the system right now. Four of those deserve naming as first-class design work, not error handling. Stale data. Every input carries an age, and the system needs a defined position on how old is too old. A price computed from data that stopped updating an hour ago is simply wrong, and it looks exactly like a right one unless staleness is modelled explicitly. Degraded modes. The choice between full service and no service is almost always a false one. A platform that can serve a reduced set of instruments, or serve prices marked as indicative rather than firm, survives conditions that take an all-or-nothing system offline. Degraded modes have to be designed, tested and visible, or they become undocumented behaviour discovered during an incident. Kill switches. An operator needs a way to stop the system faster than a deployment allows and more precisely than pulling the host. That control must be tested regularly, because an untested kill switch is a belief rather than a capability. Audit reconstruction. Somebody will eventually ask what the system did on a specific day and why. If answering that requires an engineer to reason from incomplete logs, the answer will take a week and still carry a caveat. The most dangerous architecture is usually the one whose failure behaviour was never consciously chosen. It has failure behaviour regardless. It just belongs to whoever wrote the retry loop. Performance is about the tail Average latency is close to useless as a description of a trading system. If 99.9% of requests are fast but a handful become pathological exactly when the market moves, the slow ones are the only ones that matter, because they cluster precisely when the system is most load-bearing. That clustering is the part averages actively hide. Slow responses are not scattered randomly through the day, they arrive together, during exactly the conditions that produced them: a volatility spike, a burst of market data, a garbage collection pause under load, a downstream service degrading while everything upstream retries into it. A mean computed across a trading session averages the difficult minutes into the quiet hours and reports a system that was never under stress. Watch distributions and tail latency rather than averages, and apply the same lens to throughput, queue depth and resource consumption. Markets do not care about your average day. The architecture has to survive the difficult one. Operational simplicity compounds A technically elegant system can be operationally expensive. Every additional dependency is another failure mode, every service boundary is another interface to keep honest, and every asynchronous workflow is another ordering question that has to be answered under time pressure. None of that says monoliths are better or microservices worse. Architecture should be judged against the operational problem it creates, and the useful question is whether an abstraction removes complexity or merely relocates it somewhere harder to see. In financial systems, relocated complexity is especially dangerous, because it tends to surface only under exceptional conditions, which is when you have the least time to understand it. Build for investigation, not just execution When an incident happens, engineers have to reconstruct reality from whatever the system bothered to keep. That means preserving enough to answer what the system knew, when it knew it, what decision it made, which build made that decision, which configuration was active, and what downstream systems actually received. Auditability, tracing, structured logs and correlation identifiers are not administrative overhead imposed by a control function. They are the engineering capability that determines whether an incident takes an hour or a week. Six principles The preceding sections reduce to a short list, and the list is more useful than the argument. Deterministic where possible. Same inputs, same output, or a stated reason why not. Observable by design. If a result cannot be explained afterwards, it is not finished. Explicit failure modes. Every dependency has a defined behaviour when it is absent, stale or wrong. Version the important inputs.Configuration, models and market data are inputs, not ambient conditions. Separate calculation from side effects. A pure calculation can be re-run, tested and replayed. One that writes as it computes cannot. Design for replay. Build so a result can be reconstructed with its reasoning, not just its value. None of these are exotic. They are unglamorous, they are cheap at design time and expensive to retrofit, and the difference between systems that hold up under scrutiny and systems that do not is mostly whether somebody insisted on them early. Trust is an architectural property Users trust systems that behave consistently. Operations teams trust systems they can understand. Executives trust systems whose risks are visible, and engineers trust systems whose behaviour can be reproduced. Those are four descriptions of the same underlying property, which is predictability. The highest standard for financial technology is therefore not high availability but high confidence. Design so that when the system succeeds people understand why, when it fails they understand what happened, and when it changes they understand what could be affected. That is what makes software markets can trust.","contentHash":"sha256:aa33013777671cdeaa3cb6722b8172be85441079a252e2fc768d79c0572e9e84","authorName":"Matthew Hartley","authorUrl":"https://zyvop.com/author/matthew217","authorSameAs":[],"category":null,"tags":[],"audience":"Technical professionals and readers researching software development","tone":"Professional, chief engineer perspective","readingTimeMinutes":7,"wordCount":1453,"faqs":null,"primaryTopic":null,"publishedAt":"2026-09-01T01:49:20.765Z","updatedAt":"2026-09-01T10:25:00.105Z","canonicalUrl":"https://zyvop.com/building-software-that-markets-can-trust-7ylzg"}