Platform
Resources
If you’ve ever worked on an integrated product that publishes multiple SDKs, you know how much work it takes to update and maintain them.
At Statsig, we have over 24 SDKs our customers use to log events and run experiments—and a team of just 7 devs to maintain them. Every new server-side feature meant copying and pasting evaluation logic into 10 repos, wrangling language quirks, and fighting version drift.
Last year, we finally decided to start moving all server‑side logic into one Rust binary and turning each SDK into a thin FFI wrapper. With our release of Server Core v0.1.0, we've consolidated our five most popular server SDKs (Node, Python, Elixir, Java, and Rust) into one core Rust engine.
With this change, we're now seeing up to 5x evaluation speeds (!)—and that's just the cherry on top of all the code sustainability benefits.
We’re pretty optimistic about this direction and wanted to share our learnings with other devs to hopefully help you, too, escape SDK maintenance hell.
The problem
Three years ago, we only supported one server language: Python. Today, we support ten. Each of our server SDKs had to duplicate necessary evaluation logic in their own language, like this:
Figure 1: In our legacy model, every new server-side feature required duplicating evaluation logic code in all 10 server SDKs.
This meant that every time we had a new server SDK feature, the relevant code and evaluation logic had to be redundantly implemented in every server language we supported. We’re not saying this was impossible, but it’s not easy from a resourcing perspective as a small startup. To stay scrappy, we needed to decouple dev headcount from the number of supported languages.
The solution
With this new approach—we’re calling it Server Core—the goal is to only need to write evaluation logic once in Rust. We’re rewriting language-specific SDKs to simply be bindings that pass data into that centralized Rust core. In other words, each language-specific server SDK is essentially just a thin wrapper:
Figure 2: In our Server Core architecture, language-specific SDKs act as "wrappers" to pass data into the optimized and performance-focused Rust "core".
How it works
At this point, you might be wondering if this is actually still performant. “Don’t the bindings slow things down?” Technically, yes, the bindings themselves do add some latency. Enter Rust.
With Rust's memory safety, performance, concurrency, and zero-cost abstractions, the improvements to actual evaluation time have been huge enough to outweigh the binding costs. That's what's so awesome about the language, and it’s why so many other modern development platforms and companies are doing similar Rust-focused rewrites out there.
Here’s a comparison of our legacy Node versus our new Node Core SDKs doing a Feature Gate check, for example:
Figure 3: A performance comparison between our legacy Node SDK and Node Core SDK.
To be fair, what we’re doing isn't something the world has never seen before. Other companies like Sentry do this for specific functions that have to be optimized for performance. The difference is that a lot of teams will still keep less time-sensitive logic in native languages. What we’re doing is putting everything in Rust not only for performance, but also for long-term maintenance and code sustainability reasons.
Tools we used
We used the following FFIs (Foreign Function Interfaces) for this Rust core project:
pyo3 (Python): Getting started - PyO3 user guide
napi-rs (Node): Getting started – NAPI-RS
jni-rs (Java): GitHub - jni-rs/jni-rs: Rust bindings to the Java Native Interface
ruslter (Elixir): GitHub - rusterlium/rustler: Safe Rust bridge for creating Erlang NIF functions
Unfortunately, not all of our supported SDK languages have existing FFIs for Rust, so there’s still a lot of deep boilerplate code we’re doing behind the scenes to glue together bindings for the rest of our supported server languages. (If you’re interested in how we’re approaching those, let us know and we’ll write another blog on it soon.)
We also wanted to give a shoutout to the Rust language and learning community. A lot of us on the SDK team at Statsig weren’t familiar with Rust before taking on this project, but there was a plethora of resources available to learn and get started. Thanks, #Rustaceans 🦀
What we learned
To be completely honest, in terms of workload, this Rust core project actually makes things a little worse before they get better. It's sort of like ripping off a bandaid to allow true healing to happen. Right now, we’re in this difficult phase of (1) supporting legacy SDKs, (2) helping people migrate to Server Core SDKs, and (3) trying to create parity for all languages with new Server Core SDKs.
If we had one tip to give other teams, it would be to plan ahead and know that this can be a painful process. But it's worth it. It also really helps to have a good, dev-focused company culture and eng leaders who supports this type of work.
For more implementation details, check out our GitHub repo, Statsig docs, or reach out to us on Slack with questions.
What’s next
Moving forward, we're only implementing new server-side features in the new Server Core SDKs, and legacy SDKs will still be supported in maintenance mode. We expect that the amount of dev hours that Server Core frees up will allow us to ship even faster.
There are still a lot of issues with language-specific package managers too, and the new SDKs will still require some degree of maintenance and versioning tasks in the long term. It’s a lot going on all at once, but we’re starting to see the light at the end of the tunnel.
Our ultimate goal is to get to a point where we just do true updates to the core Rust engine, and light dev work to update bindings for language-specific ones.
Liked this content? Let us know! Join our Slack community to give feedback or ask for more details.
Join the Slack community
