Multi-channel notification service for email, SMS, push notifications, Slack and webhooks with retry logic and delivery tracking.
Provides a unified API for sending notifications across multiple channels. Supports priority queues, templates, rate limiting and delivery tracking. Started this project to learn Celery properly and needed something more flexible than existing solutions.
- Multi-channel support: Email, SMS, Push, Slack, Webhooks
- Template system with Jinja2
- Priority queues (high, medium, low)
- Retry logic with exponential backoff
- Delivery tracking 📡
- Rate limiting per channel/user
- User preferences
- Batch processing
- Scheduling
This service is designed for cloud-native deployment with full DevOps lifecycle support:
# Build and run with Docker Compose
docker-compose up --build
# Or deploy to Kubernetes with Helm
helm install notification-service ./helm/notification-service- Kubernetes: Full Helm chart support with configurable resources
- Docker Compose: Production-ready configuration with monitoring
- Auto-scaling: Built-in support for horizontal pod autoscaling
- Monitoring: Prometheus metrics integration
- CI/CD Ready: Pre-configured for deployment pipelines
# Setup
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
# Run migrations
alembic upgrade head
# Start API
uvicorn src.main:app --reload
# In another terminal, start Celery worker
celery -A src.tasks.celery_app worker --loglevel=info# Using Docker Compose (includes all services)
docker-compose up --build
# Access the API at http://localhost:8000
# Swagger UI at http://localhost:8000/docs# Deploy with Helm
helm install notification-service ./helm/notification-service --values values-prod.yaml
# Or deploy with raw Kubernetes manifests
kubectl apply -f k8s-manifests/API receives requests → validates → stores in DB → queues in Redis → Celery workers process → sends via channel services
API → DB → Redis Queue → Celery → Channel Services
Set these in .env:
DATABASE_URL=postgresql://user:pass@localhost/notifydb
REDIS_URL=redis://localhost:6379/0
SMTP_HOST=smtp.gmail.com
TWILIO_ACCOUNT_SID=your_sid
TWILIO_AUTH_TOKEN=your_token
Send email:
requests.post("http://localhost:8000/api/v1/notifications", json={
"channel": "email",
"recipient": "user@example.com",
"template": "welcome_email",
"context": {"name": "John"},
"priority": "high"
})- Docker: Multi-stage builds for optimized images
- Kubernetes: Production-ready Helm charts
- Docker Compose: Local development and staging environments
- Helm Charts: Parameterized Kubernetes deployments
- Environment-specific configs: Different values for dev/staging/prod
- Resource management: CPU/memory limits and requests defined
- Health checks: Built-in endpoints for container orchestration
- Structured logging: JSON-formatted logs for log aggregation
- Metrics: Prometheus endpoint for monitoring
pytest
# or with coverage
pytest --cov=src tests/Tests cover about 60% of the code. Need to add more edge cases.
- WebSocket support for real-time updates
- Analytics dashboard
- Discord notifications
- Better template error messages
- Notification cleanup job
- More integration tests
- Fix N+1 query issues
The retry logic uses exponential backoff (max 5 retries). After that notifications are marked failed.
Rate limiting varies by channel - email has higher limits than SMS.
Template rendering can fail if context vars don't match template. Need better validation.
Started this in early 2023 and it took longer than expected. Celery was trickier to configure properly than I thought!
DevOps-wise, spent considerable time optimizing the Docker images and creating robust Kubernetes deployments. The Helm chart supports all the major configuration options you'd need in production.
MIT
Mario Perez - DevOps Engineer