Drasi vs Event-Driven Technologies Decision Framework
Purpose
When to use Drasi's continuous query model vs traditional event-driven patterns (Kafka, Event Hubs, Azure Functions, polling). This is the #1 question architects ask when evaluating Drasi.
Decision matrix
| Factor | Drasi (continuous queries) | Event-driven (Kafka/Event Hubs) | Polling |
|---|---|---|---|
| Detection model | Consumer-defined queries against live data | Producer-defined event streams | Periodic database queries |
| Change semantics | Precise added/updated/deleted with before/after | Event payload (producer decides shape) | Snapshot diff (compute-intensive) |
| Multi-source correlation | Single query spans multiple Sources | Requires stream processing (Flink, Kafka Streams) | Application-level joins |
| Latency | Near-instantaneous (CDC-driven) | Low (event-driven) | Poll interval (seconds to minutes) |
| Compute cost | Only when data changes | Continuous broker infrastructure | 99% idle polls returning "nothing changed" |
| Query flexibility | Cypher/GQL — declarative, version-controlled | Code-based processors | Code-based diff logic |
| Operational complexity | Low (declarative config) | High (broker, partitions, consumer groups) | Medium (scheduler, diff logic) |
| Schema evolution | Source-dependent (verify per provider) | Schema registry + compatibility | Application-level handling |
When Drasi is the right choice
- Consumer-defined change detection: The person who needs to react to changes should define what changes matter, not the producer.
- Multi-source correlation: A single query needs to span PostgreSQL + Event Hub + Dataverse and correlate changes across them.
- Precise change semantics: You need to know exactly which rows were added, updated (with before/after), and deleted, not just "something changed."
- Low write-to-read ratio: Changes happen infrequently relative to how often you'd poll. Drasi's compute activates only on actual changes.
- Multiple parallel detection rules: 10+ independent queries watching the same data (SLA monitoring, fraud detection, security alerts).
- Declarative, version-controlled logic: Query logic should be reviewed, versioned, and audited like code.
When event-driven is the right choice
- High-throughput event streaming: >100K events/sec with partitioning, ordering, and replay requirements.
- Event sourcing / audit trail: Full event history with replay capability is a core requirement.
- Loose coupling: Producers and consumers are independently deployed and scaled.
- Existing Kafka/Event Hub infrastructure: Broker is already operational and team has expertise.
When polling is acceptable
- Very low frequency: Check once per hour/day, data rarely changes.
- Simple single-source: One database, one check, no correlation needed.
- No CDC available: Source doesn't support logical replication or change feeds.
- Prototype / throwaway: Quick proof of concept where infrastructure investment isn't justified.
Drasi + Event Hubs combination
Drasi can consume Event Hubs as a Source, they're complementary, not competing:
Event Hub (high-throughput ingestion) → Drasi Source → Continuous Query (correlation/filtering) → Reaction (targeted action)Use Event Hubs for ingestion and Drasi for the "what matters?" layer.
Cost model
| Component | Drasi cost | Event-driven cost |
|---|---|---|
| Infrastructure | Kubernetes cluster (shared) or Drasi Server (single process) | Kafka cluster / Event Hubs namespace |
| Compute | Only when Source data changes | Broker always running + consumer processes |
| Query eval | Per-change, bounded by query complexity | N/A (processor code runs per event) |
| Storage | Query state store (Redis/RocksDB/in-memory) | Topic retention + consumer offsets |
Break-even: Drasi is typically cheaper when <100K events/sec and you need multi-source correlation or consumer-defined logic. Event-driven is cheaper at >100K events/sec with simple per-event processing.