Any support for CQRS Architectural Pattern?

[marcellodesales]

We do need to listen to events from the graph based on specific properties and the Hypergraph might be great place to fetch those!

[1pxone]

Right now RushDB is CQRS-friendly, but we don’t yet ship a full “subscriptions layer” (webhooks / SSE / WebSockets) as a first-class feature.

How it works today:
• Write side (commands)
• Your app sends mutations to RushDB (JSON-in → graph).
• You can model domain events explicitly (e.g. OrderCreated, StatusChanged) as records/relationships in the graph in the same logical operation.
• Read side (queries / Hypergraph)
• The Hypergraph is a great place to build read models: you can query by properties, relationships, labels, etc. with very little ceremony and project exactly the shape your projections need.
• Event stream (today)
• For push-style flows we recommend an app-side event stream right now:
• On each command, your service both
1. writes to RushDB, and
2. appends a domain event to your broker of choice (Kafka/NATS/RabbitMQ/etc.) or a simple “outbox” collection.
• Consumers subscribe to that stream and build whatever read models / projections they need (including ones that live back in RushDB).

On the roadmap we’re exploring a graph-level change feed (filtered by labels/properties) that could back webhooks / SSE / WebSockets directly, so you could say “notify me when any Deal with stage = 'Won' appears or changes” and plug it into your read side without extra glue code.

If you can share a bit more on your use-case:
• Do you need sub-second latency, or is “within a few seconds” OK?
• Roughly how many events per second are you expecting?
• Are you thinking 1–2 services consuming events, or a public multi-tenant subscription API?

That will help us align the subscriptions/webhook story with what you actually want to build.