Discussion with Mr. Yanick.

Hello everyone,

Please find below some of the key points that were mentioned during the meeting with Mr. Yanick:

## Action Items

- [ ] Investigate the Redis High Availability (HA) architecture.
- [ ] Evaluate distributed storage synchronization.
- [ ] Investigate a caching strategy to reduce costs.
- [ ] Consider an architecture with a master node that controls how data is stored across the other nodes.
- [ ] Review PostgreSQL user management and permissions.
- Avoid using the PostgreSQL admin user for the application.
- Create a dedicated application user with only the permissions required by the application (principle of least privilege).
- [ ] Decide whether we are going with RAS or staying with Kubernetes.
- Create tickets to evaluate both options.
- Define the implementation plan.
- Create tickets for:
- [ ] High availability architecture/design
- [ ] Database design
- [ ] Backup strategy
- [ ] Backup integrity verification
- [ ] Backup restoration testing
- [ ] Never cache private keys. Retrieve them only when needed, but do not cache them.
- [ ] Revisit the caching mechanism.
- If private keys must be stored temporarily, use encrypted disk storage rather than RAM.
- Disk encryption is a well-established security practice, whereas protecting data in RAM is significantly more complex.
- [ ] Re-evaluate whether caching is needed.
- If caching is required, clearly define:
- [ ] What will be cached.
- [ ] Where it will be cached.
- [ ] How it will be cached.
- [ ] The security measures that will protect the cached data.
- We need to check if we need to implement a log collector in the backend side so that the @Awambeng and @forkimenjeckayang can use that for monitoring

## Notes

- Follow the principle of least privilege for database access.
- Ensure backup integrity and restoration are tested regularly as part of the implementation.
- Design the caching strategy with security as a primary consideration.

@Hermann-Core @ndefokou @Awambeng @forkimenjeckayang @Christiantyemele @Blindspot22 @Mart @IngridPuppet

No files, tests, or entry points are specified. Start by reading any architecture, deployment, and operations documentation in the repo to locate current decisions about Redis, PostgreSQL, caching, and backups. Then review related issues/notes for RAS versus Kubernetes and database/user-permission choices to avoid duplicate work. Done means the plan is broken into concrete, scoped follow-up tickets with clear acceptance criteria for each checklist item.

由索引模型根據 Issue 內容生成。