Hello,
I am quite new to rust, and what better way to stretch the limits of my knowledge that to build something scalable, low latency and high frequency, In that regard i decided to build a end to end opensource orderbook exchange in rust (focused on crypto but the module should be general),The primary matching engine will be using rust using tokio for concurrency, but i am worried about what frameworks to use to suit the needs best. For the database the first contender is postgress with diesel framework (also considering no-sql and sqlx) and for http/websocket server rocket or actix-web. Is this architecture good enough to scale to millions of users? What would an "ideal" framework set for this be.
When you want to write high-performance code, you want to avoid thinking of “frameworks” as fundamental choices. Frameworks are libraries that constrain the way your program works in “opinionated” ways; that take over the control flow and leave you writing components that must fit into the framework.
High performance is obtained by (among other things) ensuring that your code does nothing that is not necessary. Frameworks frequently stick you with doing something unnecessary to fit into the framework.
I’m not saying “don't use libraries”. I'm saying: don't take your choice of libraries, especially frameworky libraries, as fundamental to your design. Expect to replace them when they get in the way (or not, if they turn out to be well-suited). Design your architecture in terms of what processes do what, not the specific libraries you're picking to implement them.
- “Have a HTTP server”, not “have an actix-web server”.
- “The server talks to a Postgres database”, not “the server uses Diesel”.
Performance and scalability comes from the big picture — having the right architecture — and from everyday good programming (like not accidentally writing an O(N²) algorithm), more than it does from choosing the right library.
Also, you're just getting started, and you will make mistakes, performance-affecting ones among them. You need to be prepared to notice them (with benchmarking and profiling) and fix them, and you can't just plan to get it right the first time. Go ahead and use Tokio, Actix Web, and Diesel, if those seem good to get started with. You can always change it later.
And try to keep your business logic — the stuff that implements the rules by which your exchange works — somewhat separated from how it performs IO (HTTP, database calls, etc.); putting that code in separate modules will help. That will make the rewrites less likely to introduce bugs. There's usually some awkwardly entangled parts, though; don't stress over those, either.
7 Likes
Thanks for the suggestion, Certainly the code needs to be flexible enough to accomate any libraries, something that is good right now may to good enough in the future, But since I'm quite new to the ecosystem, it would be really helpful to get some pointers / direction to choose which libraries would give me the best bang for the buck to get started with.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.