Skip to content
NexisChat Docs

Queue System

Queue System

Section titled “Queue System”

The Evolution API includes a BullMQ-based queue system for handling asynchronous operations like profile fetching and profile picture URL retrieval.

Overview

Section titled “Overview”

The queue system provides two main queues:

  • fetchProfile - For handling profile fetch requests
  • fetchProfilePictureUrl - For handling profile picture URL fetch requests

Configuration

Section titled “Configuration”

The queues use Redis as the backing store. Configure Redis connection using environment variables:

Terminal window
REDIS_HOST=localhost
REDIS_PORT=6379
REDIS_PASSWORD=your_password_if_needed

Admin Dashboard

Section titled “Admin Dashboard”

The BullMQ dashboard provides a visual interface for monitoring and managing queues.

Accessing the Dashboard

Section titled “Accessing the Dashboard”

The dashboard is available at:

GET /admin/queues

Authentication

Section titled “Authentication”

The admin dashboard requires API key authentication using the same system as other Evolution API endpoints.

Headers:

apikey: YOUR_API_KEY

Features

Section titled “Features”
  • Visual Queue Management: Monitor job status, retry failed jobs, and view queue statistics
  • Real-time Updates: Live updates of queue status and job progress
  • Job Retry Logic: Automatic retry with exponential backoff (3 attempts, starting at 2 seconds)
  • Error Handling: Comprehensive error logging and monitoring

Queue Workers

Section titled “Queue Workers”

The system includes placeholder workers for both queues. These workers are automatically initialized when the application starts and are ready for custom business logic implementation.

Worker Configuration

Section titled “Worker Configuration”
  • Retry Attempts: 3 attempts per job
  • Backoff Strategy: Exponential backoff starting at 2 seconds
  • Connection: Uses the same Redis configuration as the queues

Implementation Notes

Section titled “Implementation Notes”
  • The queue service is automatically initialized during application startup
  • Workers are placeholder implementations - actual business logic needs to be added
  • The system is designed for horizontal scaling with Redis as the backing store
  • All queue operations are logged for monitoring and debugging

Next Steps

Section titled “Next Steps”

To fully implement the queue system:

  1. Add actual fetchProfile logic in the worker
  2. Add actual fetchProfilePictureUrl logic in the worker
  3. Implement proper error handling for specific use cases
  4. Add monitoring and alerting for failed jobs
  5. Consider adding job scheduling if needed
Section titled “Related”