// the find
dotnetcore/CAP
Distributed transaction solution in micro-service base on eventually consistency, also an eventbus with Outbox pattern
CAP is a .NET library that implements the Outbox Pattern for distributed transactions, bundling message publishing and database writes into a single local transaction so messages can't get lost if the broker goes down. It also functions as a general event bus with pluggable transports (Kafka, RabbitMQ, Azure Service Bus, NATS, etc.) and storage backends (SQL Server, PostgreSQL, MySQL, MongoDB). The target is .NET microservice teams who need guaranteed message delivery without building their own outbox infrastructure.
The transport and storage abstraction is genuinely well done — swapping RabbitMQ for Kafka is a one-line config change, and the same is true for switching databases. The built-in dashboard with real-time message status and manual retry is something most teams end up building themselves; having it as a NuGet package is a real time-saver. Native delayed message support without relying on broker-specific scheduling features (RabbitMQ delayed-message plugin, etc.) is a concrete advantage. OpenTelemetry instrumentation is built in, so distributed traces across service boundaries work without extra plumbing.
The subscriber marker interface (`ICapSubscribe`) is a leaky abstraction — your business services end up with a CAP dependency just so the framework can discover them via reflection, which is the kind of coupling an outbox pattern is supposed to avoid. Message ordering guarantees are inconsistent across transports: serial processing is opt-in per consumer, and with Kafka you're effectively on your own for partition-level ordering. The dashboard's Vue frontend is shipped as pre-built static assets in the NuGet package with no documented way to rebuild it, which is a maintenance liability. There's no built-in dead-letter queue management beyond manual retry via the dashboard — teams with high failure rates will feel that gap.