# Reaqtor: stateful, distributed event processing on Rx in .NET

> Reaqtor is a .NET Foundation project for reliable, stateful, distributed and scalable event processing built on Reactive Extensions, with the documentation written as runnable C# notebooks. It is a decade-old framework that powers services at Bing and M365, and the statefulness is the whole point.

**reaqtive/reaqtor** — Reaqtor is a framework for reliable, stateful, distributed, and scalable event processing based on Rx.

- Repository: https://github.com/reaqtive/reaqtor
- Website: https://reaqtive.net/
- Stars: 648 · Forks: 38
- Language: C#
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/reaqtive-reaqtor

## Event processing where the state has to survive

The README describes Reaqtor as a framework for reliable, stateful, distributed and scalable event processing based on Reactive Extensions, and that list of adjectives is the specification.

Three of the four words point at the same idea. Reliable means a processing failure does not lose the work in flight. Distributed means the work can be spread across processes. Scalable means it can grow. And stateful is the word that distinguishes this from ordinary Rx, because an ordinary reactive stream is a one-way pipe: subscribe, receive, dispose, and the history is gone. A stateful stream has a position, and something can pick up from that position rather than starting over.

That is what makes it a framework rather than a library. Reactive Extensions itself gives you a push-based abstraction over events, which is exactly what Reaqtor builds on, and the addition is durability and position. For a service that has to keep consuming a feed of events without losing its place, that is the whole problem, and the README is not vague about it.

The project is part of the .NET Foundation, which brings with it both governance and a particular contribution process, which comes up later.

## Ten years of production use behind the API

The About section gives the pedigree in two sentences. Reaqtor has been in development for over 10 years, and it is the evolution of Reactive Extensions and powers services across Bing and M365.

That lineage explains the shape of the project better than any feature list would. A framework that started inside a search service and a productivity suite is shaped by the problems those systems have: enormous event volumes, the need to keep state, and an operational environment where a consumer that silently stops consuming is an outage. The ten years of development also mean the API has had time to settle, which is worth something in a framework you intend to depend on for a long-lived service.

It is worth being precise about the claim, though. The README says the framework powers services across Bing and M365; it does not say which features of it those services use, or how. The honest reading is that a production-proven core exists and the public API is a superset shaped by it, not that every corner of the framework is exercised at that scale.

For an evaluator, the practical question is which of its capabilities your workload actually needs. The stateful, distributed part is the hard part and the reason the project exists. The reactive part is the easy part, and plain Rx already does it.

## Building needs .NET 10 and an XML-based solution file

The build requirements are stated in one sentence, and they are not trivial. To build Reaqtor you need the .NET SDK, version 10.0 or later, and then in the root folder of the cloned repository you run:

```
dotnet build All.slnx
```

The solution file is `All.slnx`, and the .slnx extension is the newer XML-based solution format. The README says you can alternatively open it in Visual Studio 2022, version 17.13 or later, or JetBrains Rider, version 2024.3 or later, and build it the usual way, and it is explicit that those versions are the ones that support the XML-based .slnx solution format.

So the toolchain requirement is real rather than incidental. An organisation on an older .NET SDK cannot build this without moving, and an organisation on a .NET version between 10 and current will be building against a target that is still moving.

The repository root supports that reading. There is a `global.json` file, which is how the SDK version is pinned for a repository, a `version.json` for the package version, `Directory.Build.props` and `Directory.Build.targets` for shared build settings, and `Directory.Packages.props` for central package version management. That last file is the pattern for a large repository where the same package appears in many projects and the versions have to stay in step.

## The documentation is C# notebooks you actually run

The most distinctive thing about the repository is that many of the examples in the documentation take the form of notebooks, and the README goes out of its way to make them runnable.

Because Reaqtor is a .NET technology, these notebooks contain C#, which means you need a Jupyter notebook editor with support for a .NET kernel. The path it recommends is Visual Studio Code with the .NET Interactive Notebooks extension, installing VS Code from code.visualstudio.com and then the free .NET Interactive Notebook extension from the marketplace.

There are three practical wrinkles in the README, and they are the kind of detail that saves an afternoon. VS Code may ask whether you want to trust the file, and you need to indicate that you do if you want to run the code. If you already have tooling for running Python notebooks, VS Code will ask which kernel to use, and you should select .NET Interactive rather than a Python kernel. And you have to have built Reaqtor first, because these example notebooks load the libraries built by the source in the repository.

That last point is the substance of the approach. The documentation is not prose describing behaviour, it is code that executes against the build you just made, so the examples cannot drift away from the implementation without someone noticing.

## An archive, a migration note and an unusual directory name

The top-level layout of the repository is the clearest evidence of a project with a long history and an active migration.

There is an `archive` directory, which is what a project keeps when it wants to preserve something without carrying it in the main build. There is MIGRATION-NET10.md at the root, which is a document about moving to .NET 10 and therefore the place to look if your build fails or your packages behave differently on the new target. There is Docfx for the documentation build, `config` and `eng` for the repository's own configuration and engineering scripts, Resources for shared assets, and `Common`, `Reaqtive` and `Reaqtor` as the code roots.

The directory called `Nuqleon` is the one that makes a newcomer stop. It is the name of the internal project that became Reactive Extensions, and it is kept here as a separate root rather than being folded into the main source tree, which is a reminder that the ten years of history are visible in the file layout and not only in the changelog.

The build and test plumbing is also visible: azure-pipelines.yml and azure-pipelines-build-jobs.yml for CI, codecoverage.runsettings for coverage configuration, and a .editorconfig for formatting. The build status badge in the README points at an Azure DevOps pipeline under the dotnet organisation, and the coverage badge points at codecov.

## Contributing means signing the .NET Foundation CLA

The contribution process is documented in more detail than most projects bother with, and it is worth knowing before you open a pull request.

The README explains the rationale: by signing a contributor license agreement, the project ensures that the community is free to use your contributions. The .NET Foundation Contributor License Agreement is linked as a PDF for review, and the process is described as follows. When you contribute to a .NET Foundation open source project on GitHub with a new pull request, a bot evaluates whether you have signed the CLA, and if it is required, the bot comments on the pull request with a link to the system where the agreement can be accepted.

That is a real, mechanical step in the contribution path, not a formality, and it is the one thing in this repository that could surprise a contributor who expects the usual GitHub flow.

The rest of the governance is standard. There is a code of conduct adapted from the Contributor Covenant, and the README links the code of conduct FAQ and a contact address. The Acknowledgements section points at A History of Reaqtor by Bart De Smet, which the README describes as a list of the people who contributed to the development of Reaqtor, and that document is where the project explains its own history in more detail than the README does.

## MIT licensed, no tagged releases, and a .NET Foundation project

The licence is MIT, with the LICENSE file at the repository root and a badge in the README that says the same thing. For a framework intended to be embedded in long-lived services, a permissive licence with no copyleft obligation is what most teams will want.

The repository has no GitHub releases, so there is no tagged version to point at and no release notes to read in that place. The distribution channel is NuGet, with a badge linking to the reaqtive NuGet profile, and the version lives in version.json at the root.

The repository is not archived and the last push was on 2026-10-17, so the branch is current. With a framework that has been in development for over ten years and is part of the .NET Foundation, the interesting question for a new adopter is not whether the project is alive but where its centre of gravity is. A .NET 10 migration note at the root, a central package version file, an XML-based solution format and a build pinned by global.json all point the same way: the current work is keeping a large, mature framework building and running on a modern .NET, rather than adding new surface to the public API.

That is a good reason to read the migration note and the current NuGet version before you plan an adoption, and a poor reason to expect a release cadence you can schedule around.

## Conclusion

Reaqtor fits a .NET team that already works in Reactive Extensions and needs event processing where state and replay matter, such as a service that must survive a restart and continue where it left off. It is the wrong choice for a project that only needs a subject and a couple of operators, since plain Rx covers that, and the wrong choice if you cannot take on a .NET 10 toolchain and an XML-based solution format. Verify first that your broker or store is one Reaqtor can persist into, that the migration notes in the repository apply to your current .NET version, and how much of the framework you actually need beyond the reactive base.

## FAQ

### What is Reaqtor used for?

The README describes Reaqtor as a framework for reliable, stateful, distributed and scalable event processing based on Reactive Extensions. It is part of the .NET Foundation, has been in development for over 10 years, and powers services across Bing and M365.

### How do I build Reaqtor from source?

You need the .NET SDK version 10.0 or later, then clone the repository and run dotnet build All.slnx in the root folder. You can also open All.slnx in Visual Studio 2022 from 17.13 or JetBrains Rider from 2024.3, which are the versions that support the XML-based .slnx solution format.

### What do I need to run the Reaqtor example notebooks?

A Jupyter notebook editor with a .NET kernel, such as Visual Studio Code with the .NET Interactive Notebooks extension. You must trust the file when prompted, select the .NET Interactive kernel rather than a Python one, and build Reaqtor first, because the notebooks load the libraries built from the source in the repository.

### What licence is Reaqtor released under?

MIT, with the LICENSE file at the repository root. The packages are published on NuGet under the reaqtive profile, and the repository has no GitHub releases, so the NuGet version is the release marker.

### Do I have to sign anything to contribute to Reaqtor?

Yes. The README explains that a bot evaluates whether you have signed the .NET Foundation Contributor License Agreement when you open a pull request, and comments on the pull request with a link where the agreement can be accepted if it is required.

## Sources

- [Issues](https://github.com/reaqtive/reaqtor/issues)
- [License: MIT](https://github.com/reaqtive/reaqtor/blob/main/LICENSE)
- [Project website](https://reaqtive.net/)
- [README](https://github.com/reaqtive/reaqtor/blob/main/README.md)
- [reaqtive/reaqtor on GitHub](https://github.com/reaqtive/reaqtor)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/reaqtive-reaqtor