Elasticache Configuration

Overview

This document outlines the ElastiCache Redis configuration for the SMART360 production environment. The setup uses a single Redis cluster with multiple logical databases to serve different microservices for message brokering (Celery/Celery Beat) and caching purposes.

ElastiCache Cluster Specifications

Database Allocation

The Redis cluster uses separate logical databases for each microservice to maintain data isolation:

Connection Configuration

Environment Variable Pattern

Each microservice connects to its dedicated database using the following pattern:

CELERY_BROKER_URL=redis://elasticache-prod.abcd.0001.use1.cache.amazonaws.com:6379/{database_id}

Example Configurations

# Auth service
CELERY_BROKER_URL=redis://elasticache-prod.abcd.0001.use1.cache.amazonaws.com:6379/1

# BX service
CELERY_BROKER_URL=redis://elasticache-prod.abcd.0001.use1.cache.amazonaws.com:6379/2

# WX service  
CELERY_BROKER_URL=redis://elasticache-prod.abcd.0001.use1.cache.amazonaws.com:6379/7

# Notification service
CELERY_BROKER_URL=redis://elasticache-prod.abcd.0001.use1.cache.amazonaws.com:6379/8

Use Cases

Primary Functions

• Message Broker: Handles Celery task queues for asynchronous processing
• Scheduler: Supports Celery Beat for scheduled tasks
• Caching Layer: Django application-level caching for improved performance

Benefits of Multi-Database Setup

• Data Isolation: Each microservice has its own logical database
• Simplified Management: Single cluster reduces operational overhead
• Cost Efficiency: Shared infrastructure across all services
• Consistent Performance: All services benefit from the same Redis instance specifications

Architecture Integration

ECS Microservices → ElastiCache Redis Cluster
├── auth service → Database 1
├── bx service → Database 2  
├── cx service → Database 3
├── mx service → Database 4
├── onboarding service → Database 5
├── rx service → Database 6
├── wx service → Database 7
└── notification service → Database 8

Security Configuration

• Network Security: ElastiCache cluster deployed within the same VPC as ECS services
• Access Control: Connection strings stored as environment variables in ECS task definitions
• Encryption: Standard AWS ElastiCache security configurations applied

Current Monitoring Setup

Basic Monitoring

• AWS CloudWatch: Default ElastiCache metrics available
• Alarms: No custom alarms configured

Operational Considerations

Current Limitations

• Single Point of Failure: Single node setup
• No Automatic Backups: Backup configurations not implemented
• Limited Monitoring: Basic AWS metrics only
• Access Restriction: ElastiCache only accessible from within AWS VPC

Troubleshooting Quick Reference

Accessing ElastiCache for Troubleshooting

Primary Access Method:

• AWS Console: ElastiCache Dashboard → Select cluster → Connect via Redis CLI interface
• From ECS Services: Only ECS containers within the VPC can directly connect

Common Diagnostic Commands (via AWS Console)

# Check overall cluster health
INFO server

# Monitor database usage per microservice
INFO keyspace

# Check memory usage
INFO memory

# Monitor connection statistics
INFO clients

# Check performance stats
INFO stats

Performance Monitoring (via AWS Console)

# Monitor real-time commands
MONITOR

# Check slow queries
SLOWLOG GET 10

# Check database-specific info
SELECT 1  # Switch to auth service database
KEYS * # Lists all keys

ECS Container Troubleshooting

# From within ECS container (if needed)
# Test connectivity to ElastiCache
nc -zv elasticache-prod.abcd.0001.use1.cache.amazonaws.com 6379

Document Version: 1.0
Last Updated: June 2025
Maintained By: DevOps Team

Note: This configuration serves 8 microservices using logical database separation. Consider implementing the recommended monitoring and backup strategies for production stability.