When you decide to go event-driven with Genesys Cloud, the next question is which real-time mechanism to build on. Genesys offers more than one, and the right choice depends on your cloud, your latency tolerance and how much plumbing you want to own. Here's a field guide.
The three common paths
1. Genesys Cloud EventBridge integration
Genesys can publish events directly to AWS EventBridge.
- Best when: you're on AWS, or you want managed fan-out to Lambda, SQS and downstream AWS services without running your own consumer.
- Strengths: native, durable, no socket management.
- Watch for: it lands you in the AWS event ecosystem — bridging to Azure or on-prem is an extra hop.
2. The Notification API (WebSocket)
Subscribe to topics over a WebSocket and receive events as they happen.
- Best when: you need low-latency, fine-grained topic subscriptions and you're comfortable managing connections.
- Strengths: broad topic coverage, genuinely real-time.
- Watch for: you own connection lifecycle, channel limits, reconnection, resubscription and ordering. It's the most flexible and the most plumbing.
3. Bridging to Azure Event Hubs (or another broker)
Consume Genesys events and republish them to Azure Event Hubs, Kafka or RabbitMQ for your own ecosystem.
- Best when: your estate is Azure-native or you already standardize on a message broker.
- Strengths: decouples Genesys from consumers, gives you replay, partitioning and a familiar operational model.
- Watch for: you need a reliable bridge in between — that's the component that has to handle dedup, watermarking and backpressure.
Quick comparison
| Path | Best cloud fit | Latency | Plumbing you own | Replay |
|---|---|---|---|---|
| EventBridge | AWS | Low | Low | Via AWS services |
| Notification API | Any | Lowest | High (sockets) | No (you buffer) |
| Event Hubs bridge | Azure | Low | Medium (the bridge) | Yes |
The decision usually isn't "which API" — it's "who runs the bridge"
Every one of these paths gets you events. What separates a weekend prototype from a production system is everything after ingress: deduplication, ordering for sequence-sensitive KPIs, watermarking, retry, and computing the actual metric once so every consumer agrees.
That's the layer Streamvane's reactive engine provides. It can ingest from the Notification API or a broker, normalize and compute KPIs once, and then deliver to cloud event buses, Azure Event Hubs or any message broker — without you hand-rolling the hard parts on each path.
A pragmatic recommendation
- All-in on AWS, want managed simplicity? Start with EventBridge.
- Azure-native estate? Bridge to Event Hubs and keep your ecosystem consistent.
- Need the broadest topic coverage and lowest latency, and have the engineering to run sockets? Notification API — but put a hardened consumer in front of it.
In every case, decide early where the KPI is computed. If it's computed once, centrally, you can switch ingress paths later without rewriting downstream consumers.
FAQ
Can I use more than one path? Yes. It's common to use the Notification API for the broadest real-time coverage and a broker for fan-out to your own ecosystem. The key is a single computation layer behind them.
Which has the lowest latency? The Notification API is typically lowest because it's a direct push, but the practical difference depends far more on what your consumer does after ingress.
Do I need Event Hubs if I'm on Azure? Not strictly, but it gives you replay, partitioning and a clean decoupling that pays off as the number of consumers grows.
Not sure which ingress path fits your estate? Book an architecture call — we'll recommend the path that minimizes the plumbing you have to own.