SB2318/UltimateHealth

Description Separate background Kafka consumers/workers from the main API infrastructure so background processing does not compete directly with API workloads. Tasks Identify existing Kafka consumers. Separate worker processes from the API service. Configure dedicated worker infrastructure. Configure appropriate consumer groups. Monitor Kafka consumer lag. Test worker failure and recovery. Expected Benefits More consistent API performance Independent worker scaling Better resource isolation Improved background-processing reliability

Horizontally Scale Node.js Backend Description Support running multiple backend instances to handle increased traffic and improve application availability. Proposed Architecture Load Balancer | +--------+--------+ | | | Node #1 Node #2 Node #3 Tasks Ensure backend is stateless. Identify and remove instance-local state where required. Configure multiple backend instances. Introduce a load balancer. Configure health checks. Test traffic distribution. Test failure of an individual instance. Expected Benefits Higher request capacity Better availability Independent backend scaling Reduced dependency on a single instance

Move MongoDB to Dedicated Infrastructure Description Separate MongoDB from the main application instance so that database resources are isolated from application workloads. Tasks Evaluate suitable MongoDB infrastructure. Set up the new MongoDB environment. Configure secure application connectivity. Migrate existing data. Verify application functionality. Configure backups and recovery. Monitor database performance. Expected Benefits Better resource isolation Improved database reliability Independent scaling Easier maintenance and monitoring

Description Move the VeriWise Python checker to a separate instance to improve service isolation and overall application stability. Currently, the checker shares infrastructure with other application services. Separating it will allow the checker and the main application to operate independently and scale as needed. Proposed Changes Set up a separate instance for the VeriWise checker. Deploy and configure the Python service on the new instance. Update the application configuration to communicate with the new instance. Verify the checker functionality after migration. Remove the existing deployment from the main application instance once the migration is confirmed. Acceptance Criteria VeriWise checker is running successfully on a separate instance. Application can communicate with the new checker. Existing checker functionality remains unaffected. Old deployment is removed after successful verification. Expected Benefits Better service isolation Improved application stability I

Description When some application/container running inside Docker encounters an exception or crashes, the entire UltimateHealth server instance on AWS Lightsail becomes unreachable and starts returning connection timeouts. A single application failure should not cause the entire server instance to become unavailable. Observed Behavior Docker application encounters an exception/crash. The container may stop or restart. Shortly afterward, the entire Lightsail instance becomes inaccessible. HTTP requests result in connection timeout. The server may also become inaccessible through SSH. Possible Causes to Investigate Out-of-memory (OOM) condition CPU exhaustion Docker container restart loop Disk space exhaustion Investigation Check: free -h df -h uptime docker ps -a docker stats --no-stream sudo dmesg -T | grep -i -E "oom|killed process|out of memory" Expected Behavior If an application crashes: Only the affected container should fail/restart. Other applications should remain availabl