Deployment architecture

Introduction#

How the bot runs in the wild. One CLI, three modes: bot, scheduler, webhook. Local/VPS, Docker, and the usual PaaS options, plus how daemon mode changes logging and process shape.

Project structure#

The application follows a modular structure :

  • CLI entry point orchestrating all operations
  • Core utilities for configuration and daemon management
  • Server implementations for Telegram, webhook, and scheduler
  • Runner modules encapsulating update and notification logic
  • Services and clients for external integrations

Core components#

The deployment architecture centers on four primary components:

CLI orchestration layer#

The main entry point is the CLI for all operational modes:

  • Command parsing with subcommands for bot, scheduler, webhook, and data operations
  • Global daemon mode flag propagation
  • Centralized logging initialization with verbose mode support
  • Graceful error handling and user interruption management

Daemon management system#

Unix-style daemonization :

  • Double-fork process isolation
  • PID file management for process tracking
  • Signal-based graceful shutdown
  • Automatic cleanup of stale PID files
  • Separate logging redirection for daemon processes

Scheduling infrastructure#

APScheduler-based automation :

  • Configurable update cycles across multiple IST time slots
  • Independent scheduler server decoupled from the Telegram bot
  • Job persistence and restart resilience
  • Timezone-aware scheduling with Asia/Kolkata timezone

Operational servers#

Three specialized servers with distinct responsibilities:

  • Telegram bot server with command handlers and administrative controls
  • FastAPI webhook server with health checks and notification endpoints
  • Scheduler server orchestrating automated update workflows

Architecture overview#

Separate processes, each with a job:

Detailed component analysis#

CLI command processing flow#

The CLI orchestrates all operational modes through a centralized dispatch mechanism:

Daemon process lifecycle#

Daemonization steps:

Scheduling architecture with APScheduler#

The scheduler implements a detailed update automation system:

Logging strategy and configuration#

The logging system adapts to operational modes:

Server-Specific architectures#

Telegram bot server#

The Telegram bot server provides user interaction capabilities:

  • Command handlers for user registration, status checking, and statistics
  • Administrative commands for system management
  • Integration with database services for user management
  • Polling-based message reception with graceful shutdown

Webhook server#

The FastAPI-based webhook server exposes:

  • Health check endpoints for monitoring
  • Web push subscription management
  • Notification delivery endpoints
  • Statistics endpoints for operational insights
  • CORS configuration for cross-origin requests

Scheduler server#

The scheduler server orchestrates automated operations:

  • Independent from Telegram bot for reliability
  • Update jobs at midnight and 8 AM through 11 PM IST
  • Official data scrape at 12:00 PM IST
  • Job persistence and restart handling

Dependency analysis#

Dependencies:

Performance considerations#

The architecture incorporates several performance work strategies:

Asynchronous operations#

  • APScheduler integrated with AsyncIO for non-blocking job execution
  • Telegram bot uses asynchronous polling model
  • FastAPI server uses async request handling

Resource management#

  • Connection pooling for database clients
  • Lazy initialization of services to reduce startup overhead
  • Efficient message splitting for Telegram notifications

Scalability patterns#

  • Decoupled server architecture allows independent scaling
  • Modular runner components enable selective service deployment
  • Environment-based configuration supports containerized deployments

Troubleshooting guide#

Process management issues#

Common daemon-related problems and solutions:

  • Process already running: Check PID files in data/pids/ directory
  • Stale PID files: Manual cleanup required when processes terminate unexpectedly
  • Permission errors: Verify write permissions for logs and pids directories

Logging and debugging#

  • Missing logs: Verify LOG_LEVEL environment variable and log file paths
  • Debug mode: Use -v flag for verbose output in development
  • Production logging: Ensure separate log files for bot and scheduler processes

Service dependencies#

  • Telegram connectivity: Verify TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID
  • Database connectivity: Check MONGO_CONNECTION_STR configuration
  • Scheduler jobs: Confirm timezone settings and network connectivity for external APIs

Conclusion#

Three processes, shared config, daemon mode when you leave. Split the servers so a bot restart does not kill the scheduler.