BitzOrcas provides automatic request idempotency through the IdempotencyPipelineBehavior in the Mediator pipeline. Requests carrying an Idempotency-Key header are automatically deduplicated.
How it works
Request with Idempotency-Key: "req-abc123" │ ▼IdempotencyPipelineBehavior │ ├── Key exists in cache? → Return cached response immediately │ └── Key not found? → Execute handler → Cache result → Return responseInterface
Commands opt-in by implementing IIdempotentRequest:
public interface IIdempotentRequest{ string GetIdempotencyKey();}
public record CreateNoteCommand(string Title, string Content) : IRequest<Result<Note>>, IIdempotentRequest{ public string GetIdempotencyKey() => $"{Title.GetHashCode()}";}Idempotency-Key header
Clients send the idempotency key as an HTTP header:
POST /api/notesIdempotency-Key: req-abc123Content-Type: application/json
{"title": "Hello", "content": "World"}- First request: handler executes, result cached
- Duplicate request: cached result returned immediately
- Cache TTL: configurable (default: 5 minutes)
Implementation details
- Uses
IMemoryCachefor single-instance deduplication - Cache key includes the idempotency key + tenant context
- Handler results are serialized and cached for replay
- Works with
IUnitOfWork— cached results include committed transaction outcomes
Current limitations
| Limitation | Description |
|---|---|
| Single-instance | In-memory cache doesn’t share across instances |
| Memory pressure | No cache size limits — high-volume systems need bounded cache |
| No expiry notification | Cached results persist until TTL expires |
Production roadmap
For production multi-instance deployments:
{ "Idempotency": { "Backend": "Redis", "DefaultTtlSeconds": 300, "MaxCacheSize": 10000 }}See also
- Mediator pipeline diagram — Shows idempotency in the pipeline
- Caching building block — IMemoryCache infrastructure