# Redis, Messaging, and Scheduler Placement

Separate the technical driver, trigger adapter, and business behavior:

| Component | Responsibility | Location |
| --- | --- | --- |
| Redis client or pool | configuration, cluster or sentinel, connection lifecycle | `internal/infra/cache/` |
| Redis repository implementation | implement a domain-owned cache or repository port | `internal/infra/persistence/redis/` |
| MQ client | producer or consumer driver, connection and protocol mechanics | `internal/infra/mq/` |
| Producer use | publish as part of an application workflow through an injected port | `usecase/` with an interface owned by the consumer |
| Consumer entrypoint | decode, validate, acknowledge, and delegate | `internal/port/worker/consumer/` |
| Scheduler engine | engine lifecycle and registration mechanics | `internal/infra/scheduler/` |
| Scheduled job | schedule-specific trigger and delegation | `internal/port/worker/job/` |

The adapter must not contain business decisions. It converts protocol data to an application command, delegates, and maps the result back to protocol behavior. Keep retry, acknowledgment, idempotency, and shutdown semantics explicit when the component runs in a real service.