Skip to main content

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.

image.png


ElastiCache Cluster Specifications

Configuration

Value

Cluster Endpoint

elasticache-prod.abcd.0001.use1.cache.amazonaws.com:6379

Node Type

cache.t4g.small

Shards

1

Number of Nodes

1

Region

us-east-1

VPC

Same as ECS services

Engine

Redis

Database Allocation

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

Database ID

Microservice

0

Unused

1

auth

2

bx

3

cx

4

mx

5

onboarding

6

rx

7

wx

8

notification

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.

Back to top