⚙️ Backend-Specific Event Settings
Events often need fine-grained control over how they’re published—things like partitioning, headers, priorities,
timestamps, etc. Dispytch supports this via the optional __backend_config__
class attribute on any EventBase
subclass.
This lets you define backend-specific settings inside your event class in a clean, declarative way.
🧩 What Is __backend_config__
?
__backend_config__
is an optional BaseModel
that lets you pass custom options to your producer. Each backend (Kafka,
RabbitMQ, etc.) can define its own config schema.
🔎 Example
1 2 3 4 5 6 7 |
|
🪵 KafkaEventConfig
Use this config to control how events are sent to Kafka.
1 2 3 4 5 |
|
🧠 partition_by
: Dynamic Partitioning
Dispytch supports dot-notation to extract keys from deeply nested payloads and use them as Kafka partition keys.
✅ Example
1 2 3 4 5 6 |
|
If the event’s payload contains:
1 2 3 4 5 6 7 |
|
Then user123
will be used as the partition key.
🐇 RabbitMQEventConfig
RabbitMQ gives you full control over message delivery via its rich AMQP options.
1 2 3 4 5 6 7 |
|
Using this config, you can set AMQP-specific things
🔨 Implementing Custom Configs
If you're writing a custom producer (see Writing Custom Producers & Consumers), you can define your own config schema:
1 2 3 |
|
Then inspect and apply it inside your send()
method:
1 2 |
|