EventFlow: a CQRS and event sourcing framework for .NET teams that want plain async/await

What EventFlow solves, and the team it was written for

Event sourcing asks you to store state as an ordered list of domain events and rebuild current state by replaying them. CQRS asks you to keep the write model and the read model apart. Doing both by hand in .NET means writing event serialization, aggregate loading, snapshot handling, read model projection and subscription plumbing before you write a single business rule. EventFlow packages that plumbing as a framework. The README calls it "a basic CQRS+ES framework designed to be easy to use", and the feature list adds that every part of the core is an interface, so a custom implementation can replace the default one. The intended reader is a .NET team that has already decided on domain-driven design and event sourcing and wants the infrastructure to be replaceable rather than fixed. The repository topics list the surrounding stack the project expects you to bring: Elasticsearch, RabbitMQ, EventStore, sagas, .NET Core. If you have not settled on event sourcing as an architectural choice, EventFlow will not help you decide; it assumes the decision.

The async/await core and the deliberate absence of background workers

Two design statements shape how EventFlow behaves at runtime. The first is that it is async/await first: commands, event store reads and writes, and subscribers are asynchronous operations, which is why the package targets .NET Standard, .NET Core and .NET 6 and later in the 1.x line. The second is the feature line "No use of threads or background workers". That is unusual for an event sourcing framework, where a hosted service or polling thread often drains a projection queue. EventFlow instead exposes interfaces for every part of its core, and the README states that this makes it easy to replace or extend existing features with a custom implementation. In practice that means the scheduling of retries, catch-up subscriptions and projection delivery is something you compose, not something the framework runs for you. The trade-off is honest: you get no hidden thread pool to reason about, and you also get no built-in worker to keep projections current. The repository ships a docker-compose.yml that starts MS SQL Server, Elasticsearch, RabbitMQ, EventStore and PostgreSQL on the usual ports (1433, 9200 and 9300, 5672 and 15672, 1113 and 2113, 5432), which is the intended shape of a local run: infrastructure in containers, your process driving EventFlow.

Installing EventFlow and running the in-memory example

The README gives one install command. It adds the core package from NuGet, and the getting started guide at geteventflow.net is the next stop:

dotnet add package EventFlow

Storage is separate. The package status list marks EventFlow.MsSql, EventFlow.SQLite, EventFlow.PostgreSql, EventFlow.MongoDB, EventFlow.EntityFramework and EventFlow.SQL, plus EventFlow.RabbitMQ and EventFlow.Hangfire, as ported to 1.0. The same list marks EventFlow.AspNetCore, EventFlow.Elasticsearch, EventFlow.EventStores.EventStore and EventFlow.Redis as not yet ported, and marks EventFlow.Autofac, EventFlow.DependencyInjection and EventFlow.Owin as removed in 1.0. If your host is ASP.NET Core, that orange marker on EventFlow.AspNetCore is the first thing to check against your target framework. The README points to a complete example in the repository that uses an in-memory event store and in-memory read models in relatively few lines of code; that is the smallest thing to run before wiring a database. For a fuller shape, the repository also carries a shipping example based on the shipping domain from Eric Evans' book, described as in-progress but useful as inspiration at larger scale. A docker-compose.yml at the repository root brings up the backing services if you want to try a real store instead of the in-memory one.

Where EventFlow is the wrong tool

The 1.x migration is the largest practical constraint. The README states that development of version 1.0 has started and is mainly breaking changes, replacing EventFlow types with Microsoft extension abstractions, chiefly IServiceProvider and ILogger<>. It also states that not all projects are migrated yet, and the package list confirms this with orange markers on AspNetCore, Elasticsearch, EventStore and Redis. If your plan depends on one of those four, you are either on 0.x or waiting. The 0.x line is described as the current stable version, in use for almost six years, with .NET Framework support and limited Microsoft extension support through extra NuGet packages; the README says feature and bug fix releases will still be done while there is interest in the community, which is a statement about intent rather than a schedule. Two further limits follow from the design. With no background workers, a read model that must stay current needs something you write to drive it. And because every core part is an interface, the defaults are a starting point, not a finished application: the framework gives you the seams, and the wiring is yours. Teams that want an opinionated, batteries-included event store server rather than a library should look at a different layer of the stack entirely.

How EventFlow differs from EventStoreDB and from MediatR plus a hand-rolled store

The closest comparison in the repository itself is EventStoreDB. The docker-compose.yml starts eventstore/eventstore:release-4.1.3 and exposes its ports, and the README lists EventFlow.EventStores.EventStore as a package, currently marked not yet ported to 1.0. That is the clearest statement of the difference in approach: EventStoreDB is a server that stores and streams events, with its own client and operational model, while EventFlow is an in-process framework that defines aggregates, commands, events, read models and subscriptions and then delegates persistence to a store you choose. You can use both, and the external examples in the README do: one community example is configured with EventFlow, Elasticsearch, EventStore and RabbitMQ. The other common alternative is assembling MediatR for command dispatch plus a hand-written event store and projections. That gives you total control and no migration guide, at the cost of writing the serialization, aggregate loading, snapshot and subscription code yourself. EventFlow's answer is the interface-per-part design plus the shipped providers, which is a real saving when your storage choice is one of the ported ones and a real cost when it is not.

Maintenance, releases and what the licence text says

The repository is not archived, and its last push was on 2026-07-31. The most recent releases are v1.2.3 on 2025-12-06, v1.2.2 on 2025-10-11 and v1.2.1 on 2025-05-29, so the 1.x line is receiving releases at a modest cadence rather than a rapid one. Two branches carry the work: develop-v1 takes pull requests and release-v1 receives merges from it, with each commit typically representing a release; develop-v0 and release-v0 do the same for the legacy line. The README states that version 1.x documentation was pulled into the repository so code and documentation change in the same pull requests, with the compiled site at geteventflow.net and the older 0.x documentation at docs.geteventflow.net, described as a bit outdated. The upgrade cost for anyone on 0.x is the v0-to-v1 migration guide, which the README says lists the breaking changes and migration recommendations; the headline change is the move to IServiceProvider and ILogger<>. On licensing, the repository's LICENSE file is present but the metadata reports the licence as NOASSERTION, so the automated classification did not resolve it. The README itself states MIT licensed and describes that as easy to understand and use for enterprise. Treat the README claim and the repository LICENSE file as the two things to reconcile before you rely on either; this is a description of what the files say, not legal advice.

Editorial conclusion

Adopt EventFlow if you are on .NET 6+ or .NET Standard and want CQRS and event sourcing without a background worker model; the 1.x packages for SQL, MongoDB, SQLite, RabbitMQ, Hangfire and EntityFramework are already ported, while AspNetCore, Elasticsearch, Redis and the EventStore client are not. If you need .NET Framework or a fully finished 1.x surface, stay on the 0.x line or wait. Before committing, read the v0-to-v1 migration guide and confirm the status marker for every package you plan to reference, because a red or orange marker means that project is not yet ported.

Frequently asked questions

Official sources

1. eventflow/EventFlow on GitHub
2. Issues
3. Project website
4. README
5. Releases