Event-driven Architecture
Build scalable event-driven applications using a unified messaging API that abstracts away broker complexity and provides guaranteed delivery, content-based routing, and multi-cloud portability.
Event-Driven Messaging
The Dapr Pub/Sub API enables producers to publish events without needing to know who consumes them, creating naturally decoupled systems where services can evolve and deploy independently. This separation allows consumers to scale on their own timelines, absorb sudden spikes in workload, and shed load gracefully without impacting upstream systems.
Key capabilities:
- Asynchronous communication - Avoid blocking calls and process work without requiring immediate responses
- Loose coupling between services - Producers and consumers evolve independently without direct lifecycle dependencies
- Pull and push models - Choose between pull-based or push-based delivery depending on your consumption pattern
- Interoperability between systems - Integrate across languages, cloud services, and legacy systems through events
- Bulk operations - Send or receive multiple messages in a single request for higher throughput
- Secure messaging - Enforce access control on topics so only authorized applications may publish or subscribe
Guaranteed Message Delivery
Dapr Pub/Sub provides at-least-once message delivery to ensure events are never lost, even during network issues, restarts, or downstream failures. Combined with built-in resiliency policies and dead-letter queues, you get a reliable, fault-tolerant messaging layer.
Key capabilities:
- At-least-once delivery - Messages are retried automatically and not lost during failures
- Dead-lettering - Route failed messages to dedicated topics for debugging and reprocessing
- Outbox pattern - Guarantee message publication only when database transactions commit
- Message TTL - Automatically expire stale messages to prevent backlogs and reduce noise
Broker Abstraction
Use one consistent API across all message brokers and programming languages without learning each broker's client library or operational model. Swap brokers or evolve infrastructure without modifying application code.
Key capabilities:
- One API for all brokers - Kafka, RabbitMQ, Redis Streams, Azure Service Bus, AWS SNS/SQS, Google Pub/Sub, and 20+ additional brokers
- HTTP + SDK access - Publish and subscribe using HTTP only or a single SDK - no broker-specific messaging expertise required
- Infrastructure-neutral - Decouple application logic from broker configuration and operational details
- CloudEvents standard - Standardize event structure across systems with a vendor-neutral format