In support of ticket #3...
Trading Pit Overview
We're migrating to a "virtual trading pit" architecture, where a trading pit might be implemented as simply as a mailing list. There are multiple pits per exchange.
Our beta exchange, at http://t7a.org, was written as a Zope application. While this made a good proof-of-concept, it is rather monolithic, as would be any web-based application server. Changes are hard, parallel testing is almost impossible, and there are audit issues inherent in storing the master copy of the general journal in Zope. What we need to do for the next iteration is break the exchange up into independent tools and daemons, creating a much more modular and open architecture.
Requirements
The requirements include a need for the exchange to be:
- simple -- use existing well-proven open-source software with a minimum of additional code
- organic -- easy to change, easy to evolve without upgrading the whole exchange at each rev
- auditable -- master records need to be printable, human-readable, easy to archive, replicate, and verify
- trustable -- master records, orders, etc. need to be digitally signed by principals, and the signature needs to be a permanent and printable part of the archived record
- scalable -- what we do now needs to be able to scale to millions of contracts and almost as many users
- partitionable -- the exchange needs to be able to be partitioned into segregated pits, firewalled from each other, where a single pit (leased to a company for internal use, for example) might only allow information sharing between authenticated members of that pit
- hackable -- pit members need to have easy read access to the master data archive for their pit, and easy write access for document and order entry, so that they can evolve their own tools for trading, monitoring, audit, and market analysis
Architecture
An 'exchange' is a loosely connected set of trading pits. Pits in the same exchange might share common order matching, settlement, or other services, or they might not. The only thing some pits at the same exchange might have in common is that they are hosted by the same legal entity.
A trading pit might be implemented as a mailing list. Virtually all pit components are implemented as scripts which read the archives and/or are subscribed to that pit's mailing list.
One pit component, again a simple script, acts as the list moderator and pit notary, checking PGP signatures and adding authoritative timestamps.
Each ticker symbol traded in the pit is managed by a single specialist. There are multiple specialists per pit. Each specialist is responsible for one or more tickers. The specialist is responsible for order matching, settlement, and account bookeeping.
Specialists
XXX cloud picture
Implementation
Use mailman for mailing list server.
Use python script for moderator.
Write simple filters, in python, for order matching, position keeping, checkpointing, account transfer, etc. Feed each filter a series of messages on stdin at each execution, the first message(s) being a checkpoint of the prior input state. The first message(s) emitted on stdout should in turn be a checkpoint of the starting state for any downstream filters.
For instance, at startup, an order-matching filter should expect to see a series of messages representing the orders currently outstanding in the market, followed by new orders as they are created. On stdout, the filter should emit XXX
Eventually we'll want a means of querying the list archives as if they were a database. For now we should be able to get away with using tools like rsync and mairix.
XXX
