feat: implement Redis caching for business activities and consumers

- Added Redis caching to BusinessActivitiesService for findAll and findOne methods.
- Integrated Redis caching in BusinessActivityComplexesService for findAll and findOne methods.
- Enhanced ConsumersService with Redis caching for findAll and findOne methods.
- Introduced cache invalidation for partner consumers and business activities.
- Created RedisKeyMaker utility for generating cache keys for consumers, partners, and POS.
- Implemented cache invalidation services for partners and POS.
- Added Redis service methods for JSON handling and key deletion by patterns.
- Updated goods service to include caching and invalidation for goods list.
- Introduced DTO for updating goods.

Agents.md

@@ -102,3 +102,30 @@ Operational guide for AI/coding agents working in `consumer_api`.
 - Duplicate FK error seen in this repo: `sales_invoices_ref_id_fkey` (MySQL 1826). Recheck migration SQL for repeated `ADD CONSTRAINT` statements before rerun.
 - Drift that repeatedly showed in this project: missing FK/unique on `sale_invoice_tsp_attempts.invoice_id`. Validate both schema and migration SQL produce the same final state.
 - `prisma migrate status` may show up-to-date while `migrate dev` still detects drift (shadow DB/application history issue); treat `migrate dev` output as source of truth for fixing local history.
+
+## Redis Cache Conventions (May 2026)
+- Use `RedisKeyMaker` in `src/common/utils/redis-key-maker.util.ts` for all cache keys and wildcard patterns; do not inline key strings in services.
+- Keep invalidation domain-based (for example `src/modules/admin/guilds/cache/*`, `src/modules/admin/partners/cache/*`, `src/modules/pos/cache/*`) and avoid duplicating delete logic across modules.
+- For list APIs that are expensive or frequently read, prefer read-through cache with TTL and invalidation on every related write path.
+- For entity endpoints, use list + detail split:
+  - list key(s): invalidated broadly on writes,
+  - detail key(s): invalidated per entity id.
+- Partner domain rules:
+  - Shared partner cache namespace is `partners:*` (not admin-prefixed) because writes occur in both `admin/partners` and `partners` modules.
+  - Use shared invalidation service `src/modules/partners/cache/partners-cache-invalidation.service.ts` from both admin and partner write paths.
+  - Invalidate `partners:list` and `partners:{id}:detail` on partner create/update/delete and license-affecting writes.
+  - Invalidate partner license caches (activated-licenses list, charge-transactions list/detail) via the shared invalidation service.
+- POS goods rules:
+  - Cache key shape is BA + guild scoped (`pos:ba:{businessActivityId}:guild:{guildId}:goods:list`) because results combine guild-default and BA-owned goods.
+  - Invalidate POS goods cache by guild when admin guild goods/category/sku changes.
+  - Invalidate POS goods cache by business activity when consumer BA goods create/update/delete.
+- Consumer/Partner hierarchy rules:
+  - Consumer profile cache key: `consumers:{consumerId}:info`.
+  - Partner-consumer profile cache key: `partners:{partnerId}:consumers:{consumerId}:info`.
+  - On partner-consumer single read, write both keys when practical to share warm cache across modules.
+  - On consumer info update or partner-consumer update, invalidate both consumer and partner-consumer profile keys.
+  - For business activities, invalidate both list and detail layers; child updates may invalidate parent single cache when parent aggregates depend on child state.
+- Wildcard invalidation implementation:
+  - Use `RedisService.deleteByPattern` / `RedisService.deleteByPatterns` for all pattern deletes.
+  - Do not implement ad-hoc scan/delete loops inside domain services.
+  - Pattern deletion uses `SCAN` + pipelined `DEL`; multi-pattern deletes run in parallel.