# rDSN puts a microkernel between your service and the cluster it runs on > rDSN is a Microsoft framework for building distributed systems, and its shape is a small service kernel with a set of pluggable modules for applications, frameworks, tools and runtime providers. The module list is the product, and the part that stands out is an emulator that runs a whole distributed system, injects faults and replays the failures. **microsoft/rDSN** — Robust Distributed System Nucleus (rDSN) is an open framework for quickly building and managing high performance and robust distributed systems. - Repository: https://github.com/microsoft/rDSN - Stars: 970 · Forks: 212 - Language: C++ - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/microsoft-rdsn ## A kernel with parts you plug in rDSN is described as a framework for quickly building resilient distributed systems, with a microkernel for pluggable components including applications, distributed frameworks, devops tools and local runtime and resource providers, enabling their independent development and clean integration. The phrase independent development is the design goal, because a component that can be developed on its own and then dropped into a running cluster is a different proposition from a framework where everything is compiled into one binary. The project was originally developed for Microsoft Bing and is stated to have been adopted in production both inside and outside Microsoft, which is the sort of provenance that matters for a framework whose selling point is resilientness. The core is a service kernel, and everything else, the service implementations, the tooling and the runtime support, arrives as a module with its own release cycle. ## The module catalogue and its release column The module table is the clearest description of the system, and it carries a release column that is worth reading attentively because several entries are marked todo. dsn.core is the service kernel itself. dsn.dist.service.stateless provides scale out and fail over for stateless services such as microservices, and dsn.dist.service.stateful.type1 provides scale out, replication and fail over for stateful services such as storage, with dsn.dist.service.meta_server handling membership, load balancing and machine pool management for those two frameworks. On the client side, dsn.dist.uri.resolver resolves a service URL to a target machine, and dsn.dist.traffic.router does fine grained RPC request routing, splitting and forking to multiple services, for example for A/B tests, and that one is marked todo. The tool modules are the larger group. dsn.tools.common is a deployment runtime covering network, aio, lock, timer, performance counters and loggers on both Windows and Linux, together with simple toollets such as a tracer, a profiler and a fault injector. dsn.tools.nfs is a remote file copy built on rpc and aio, dsn.tools.explorer extracts task level dependencies automatically, dsn.tools.log.monitor collects critical logs across a cluster, and dsn.tools.hpc is a high performance counterpart of tools.common, also marked todo. ## Scenarios are combinations, not products The framework does not ship fixed products, it ships combinations, and the scenario table shows how the same modules are assembled differently for different goals. For logic correctness development, the combination is the example application plus the emulator plus the common tools, with a configuration file for logic only. For logic correctness with failure, the same modules are used with a different configuration that injects faults, which is the point, since the only thing that changes between the two scenarios is the configuration. For performance tuning, the combination drops the emulator and uses the application with the common tools alone, while progressive performance tuning adds the emulator back so that performance can be tuned incrementally. The table also lists a Paxos enabled stateful service scenario, which shows the replication layer being turned on for the same application. Since dsn.core is always required it is omitted from the modules column, and every module is loaded by dsn.svchost, a common process runner, with the given configuration file. That is the whole configuration model in one sentence, a process runner plus a configuration file. ## The emulator is the part worth studying dsn.tools.emulator is described as an emulation runtime for whole distributed system emulation with auto-test, replay, global state checking and so on, and it exists because the alternative is testing a distributed system by breaking a real one. The other modules in the same family support the same goal from different angles, since dsn.tools.common includes a fault injector among its toollets, and the tutorials mention codegen, auto-test, fault injection, bug replay and tracing as things built in with the tools. The replay piece is what turns a failure into a repeatable artifact, since a recorded run can be replayed against a change to see whether the fix works or whether the behaviour moved. There is a documented case study attached to the project, RocksDB made replicated using rDSN, which is the kind of evidence that the framework is more than a paper design, and the tutorial pages cover a one box cluster for understanding service registration, deployment and monitoring, and building a counter service first on one node and then with replication. ## The two replication layers, and who calls whom The distributed modules fall into two families that map to the two hard problems in a service architecture. The stateless family handles services that hold no state, so the problem is routing and fail over, and the module provides scale out and fail over for what the documentation describes as micro services. The stateful type 1 family handles services that do hold state, such as a storage engine, and provides scale out, replication and fail over, with Paxos support appearing in the scenario table as the mechanism for the stateful case. Above both sits the meta server, which is responsible for membership, load balancing and machine pool management, which is the piece that turns a set of replicated servers into something a client can address. The client side is deliberately small, since a URI resolver turns a service URL into a target machine and the traffic router sits in front of it for requests that need to be split or forked, such as a test that sends a percentage of traffic to a new implementation. ## The repository and its release state The tree shows a C++ project built with CMake, with a CMakeLists.txt at the root, src/ for the sources, include/ for the headers, ext/ for external dependencies and a compile_thrift.py script, which suggests Thrift is used for the service definitions. There is a tutorial/ directory with the example scenarios and their configuration files, deploy/ for deployment material, resources/, doc/, bin/, a run.sh and a run.cmd for the two platforms, a Release Note.txt, a SECURITY.md, and .travis.yml with appveyor.yml as the two continuous integration configurations. The plugin modules live under src/plugins and src/core in this repository, while several of the other modules in the catalogue, the distributed service and tools projects, are separate repositories. The release history is the concern. The tagged releases are 1.0.0 from 2016-10-18 and a v1.0.0-alpha from 2016-02-22, while the last push to the repository was on 2026-08-24, so the source is being maintained while the published versions have not moved in a decade. The licence is MIT. ## Conclusion rDSN fits a team that has to reason about what happens when a machine dies in the middle of a replicated stateful service, because the emulator, the fault injector and the bug replay tooling are the parts the framework is built around rather than bolted onto. It does not fit a team starting a new project today, since the tagged release is 1.0.0 from 2016-10-18 even though the last push was on 2026-08-24, and the module table still lists several components as todo. Before you invest in it, read the scenario table, because the framework only pays off if you can find a module combination matching your failure model, and check which of the pluggable components are actually released rather than planned. ## FAQ ### What is rDSN? Robust Distributed System Nucleus is a Microsoft framework for quickly building and managing resilient distributed systems, built on a microkernel for pluggable components, including applications, distributed frameworks, devops tools and local runtime providers. It was originally developed for Microsoft Bing. ### What does the rDSN emulator do? It provides an emulation runtime for whole distributed system emulation, with auto-test, replay and global state checking, so a team can test failure behaviour without breaking a real deployment, and it works alongside the fault injector in the common tools module. ### How are rDSN modules combined? All modules are loaded by dsn.svchost, a common process runner, with a given configuration file, and the documentation lists scenarios as combinations, such as the example application with the emulator for logic correctness with failure, or the same application with the common tools alone for performance tuning. ### Which rDSN modules handle replication? The stateful type 1 module provides scale out, replication and fail over for stateful services such as storage, the stateless module provides scale out and fail over for microservices, and the meta server handles membership, load balancing and machine pool management for both. The traffic router and the hpc tools module are listed as todo. ### Is rDSN still developed? The repository is not archived and the last push was on 2026-08-24, but the tagged releases are 1.0.0 from 2016-10-18 and a v1.0.0-alpha from 2016-02-22, so there is no recent published version to install. The licence is MIT. ## Sources - [Issues](https://github.com/microsoft/rDSN/issues) - [License: MIT](https://github.com/microsoft/rDSN/blob/master/LICENSE) - [microsoft/rDSN on GitHub](https://github.com/microsoft/rDSN) - [README](https://github.com/microsoft/rDSN/blob/master/README.md) - [Releases](https://github.com/microsoft/rDSN/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-rdsn