Database and cache integrations
Use PostgreSQL, MongoDB and Redis services from the Consumer application container.
A Consumer handler can resolve data services through DI, just like an HTTP or WebSocket application. It uses the PostgreSQL pool, MongoDB service or Redis service prepared in the application container instead of creating a connection for every message. Each delivery has its own handler scope.
Enable the integration you need#
| Purpose | Facade features | Public module |
|---|---|---|
| PostgreSQL, one pool | consumer, postgresql |
lilyrs::postgresql |
| MongoDB, one connection authority | consumer, mongodb |
lilyrs::mongodb |
| Redis, one service | consumer, redis |
lilyrs::redis |
| Named connections | The corresponding *-factory feature |
The same integration module |
[dependencies]
lilyrs = { version = "0.1.0", features = ["consumer", "postgresql"] }
serde = { version = "1", features = ["derive"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread"] }This selection enables ordinary PostgreSQL access. Inbox deduplication and atomic outbox writes require the compound feature and queue binding in transactional inbox. Do not combine single and factory features for the same backend in one binary.
Resolve a service from the delivery scope#
Service<T> in a handler parameter uses the delivery DI scope. Resolve your repository or business service this way; that service can inject the data integration through #[inject] fields. Do not retain a scoped dependency in the constructor of a singleton middleware or guard; resolve it with exchange.service::<T>() during delivery.
Application types using PostgreSQL repository or MongoDB collection derives must be linked into the binary. The facade supplies the required derive and registry wiring; no additional linkme or direct registry dependency is needed. The PostgreSQL and MongoDB integration guides also describe the data models; the Consumer entry point is a queue handler.
Ordinary data access and atomic processing#
| Operation | Actual scope |
|---|---|
| Ordinary DB write from a handler | A delivery can return after a lost ACK even if the database write succeeded. |
| DB write through the transaction context | Commits with inbox completion and outbox records in the same transaction. |
| Redis cache update | Remains outside the PostgreSQL or MongoDB transaction. |
| HTTP request or email | Database rollback cannot undo the external effect. |
For cache invalidation or external notifications, record the intent in an outbox first and make its downstream handling idempotent. Consumer does not provide Redis as a transactional inbox backend.
Connection and shutdown ownership#
A container created by Consumer and its integration services participate in application shutdown. If you supply a caller-owned container, the parent application closes it. Factory mode selects connections by name; a transactional queue binding and its repository or collection must use the same cell. Named connections explains this with examples.
Delivery cancellation and the data integrations’ operation context types are not interchangeable. Use transaction.operation_context() for transactional MongoDB work; for ordinary database access, follow the integration’s timeout and cancellation contract. Do not detach database work beyond the lifetime of its delivery scope.
Sources for this page v0.1.0
This guide is based on the reviewed framework commit.