Skip to content

Latest commit

 

History

History
54 lines (41 loc) · 2.49 KB

TODO.md

File metadata and controls

54 lines (41 loc) · 2.49 KB

Roadmap

  • Add redis orderbook functionality
  • Move crud operations for orders into orderbook
  • Split routes into relays/controllers and routes
  • Set async support for sqlite
  • Dockerfile and docker-compose.yaml
  • Use New approach to placing orders using redis.zrange with scores (choose 100 in range then select oldest id)

Fixes

  • Add socketio functionality
  • Test out socketio functionality with socketio
  • Update /order/{order_id} on a quantity less than traded_quantity. This truncates to traded_quantity and marks order_alive=False, however it returns { "success": True }.

Later

  • Provide auth for endpoints

  • Add alembic for maintaining migrations

  • Add logging functionality

  • Possibly add celery or another tool for workers

  • Possibly separate out trades into a separate microservice

  • Create provision for a Dead Letter Queue for failed trades

  • Add unit tests especially for orderbook

  • Replace models on api side with pydantic schemas (and move creation to crud)

  • Replace sorted sets 'ID' with an 'UpdatedAt' approach. Since this system could be gamed!

Improved Design

  • Workers:

    • celery and flower: Celery workers can be used to attempt to perform trades from a redis stream
    • gcloud functions + gcloud cloud scheduler (for setting up polling functions)
  • redis stream: Stream to store (bid, ask) pairs which can be processed async by celery workers

  • Polling: Used to generate (bid, ask) pairs from redis sorted_sets to the redis stream

  • redis sorted sets: Two redis sorted sets (one for ask, other for bid) used for forming the orderbook

  • gcloud memorystore for redis: Memorystore for maintaining read replica or for having a redis cluster (if multi-location)

  • postgres: Acts as transactional database for maintaining orders and trades

  • asyncpg: Lib for async queries on Postgres for updating orders etc.

  • Polling System could also be done using gcloud functions + gcloud scheduler (in which case a simple attempt_trade microservice could be setup to poll on the memorystore redis instance)

Issues with current implementation

  • Separation into multiple microservices would be preferred.
  • New proposed design could be used
  • No preference is given to the time the order arrived.
  • Later bid orders are often preferred. (but earlier ask orders are preferred)