Yaroslav Smirnov

Solar Tutor AI Bot

Production-grade AI education platform serving 500+ active users. Implements 4-layer multi-provider AI failover, automated subscription lifecycle management, and custom application-level DDoS protection. Processes 1,000+ AI generations daily with 99.9% uptime.

Why This Project Matters

Manual content creation is a bottleneck for education platforms. Teachers need automated lesson plan and exercise generation, but relying on a single AI provider creates reliability risks—geographic restrictions, quota exhaustion, and provider outages directly impact user experience.

This system solves three interrelated problems:

  1. Availability: Geographic API restrictions (OpenAI blocks certain regions) require fallback mechanisms beyond simple retries.
  2. Cost Efficiency: Multi-provider orchestration (OpenAI, Gemini, Groq) allows intelligent routing based on task type, cost, and latency.
  3. Scale: Supporting 500+ concurrent users with differentiated quotas requires sophisticated database patterns and async I/O design.

The technical challenge is non-trivial: coordinating multiple external APIs, maintaining user state across failovers, managing subscription quotas atomically, and protecting against both DDoS attacks and API rate limits simultaneously.

System Architecture & Design

Backend Design Philosophy

The platform implements a highly available async-first architecture designed for reliable AI processing at scale:

Async-First Core

Multi-Provider AI Orchestration (4-Layer Failover)

  1. Layer 1 (Direct): OpenAI GPT-4 direct API calls for optimal quality
  2. Layer 2 (Regional Routing): Google Gemini as cost-effective alternative with similar quality
  3. Layer 3 (Fallback): Groq for latency-sensitive operations (extremely fast inference)
  4. Layer 4 (Proxy): Cloudflare Workers & Netlify Functions for regions with API restrictions

Each layer tracks cost, latency, and quota exhaustion. Automatic provider switching occurs when:

Connection Pool & Database Engineering

Subscription & Quota Management

Security & DDoS Protection

Service Architecture

Telegram Bot (Entry Point)
    ↓
Message Router & State Machine
    ↓
Async Request Handler
    ├─→ Quota Validation (DB lookup + atomic decrement)
    ├─→ AI Provider Selector (cost/latency/availability logic)
    ├─→ Multi-Provider Orchestrator
    │   ├─→ Direct API calls
    │   ├─→ Failover retry logic
    │   └─→ Response validation
    ├─→ Content Moderation (Llama Guard)
    └─→ Result Storage & User Notification

Payment & Subscription Worker (Background)
    ├─→ Daily quota reset
    ├─→ Subscription renewal checks
    ├─→ Auto-removal of expired subscriptions
    └─→ Renewal notification dispatch

DDoS Protection Layer
    ├─→ Rate limit checking (in-memory counter)
    ├─→ Pattern analysis (behavior detection)
    └─→ User blocking escalation

Key Technical Features

Technologies & Stack

Backend

AI & ML

Database & Persistence

Infrastructure & DevOps

Payment Integration

Tooling & Utilities

Tangible Impact

Engineering Challenges & Trade-offs

Challenge 1: Multi-Provider Failover Complexity

Problem: Different AI providers have different API signatures, error behaviors, quota systems, and geographic restrictions. Coordinating transparent failover while maintaining consistent output quality is non-trivial.

Solution Implemented:

Trade-off: Added 20% overhead in code complexity for 99.9% reliability. Alternative was single provider with higher incident rate.

Challenge 2: Atomic Quota Management at Scale

Problem: Concurrent requests from 500+ users consuming quotas simultaneously creates race conditions. A user could exceed quota if quota checking and decrement aren’t atomic.

Solution Implemented:

Trade-off: Row locks add ~50ms latency per request but eliminate race conditions. Accepted for user fairness. Optimization: batch quota resets to minimize lock contention.

Challenge 3: Geographic API Restrictions

Problem: OpenAI blocks requests from certain geographic regions. Cannot serve all users with single provider endpoint.

Solution Implemented:

Trade-off: Proxy layers add 100-300ms latency but enable service availability. Acceptable for educational use case.

Challenge 4: Subscription State Consistency

Problem: Subscription lifecycle involves multiple steps (payment webhook → user notification → group membership update → quota allocation). Failure at any step leaves inconsistent state.

Solution Implemented:

Trade-off: More complex state machine but no orphaned subscriptions. Simpler alternative would be eventual consistency with cleanup jobs.

Challenge 5: Content Moderation at Speed

Problem: Generated content must be checked for safety before delivery. Adding moderation adds latency to user-facing requests.

Solution Implemented:

Trade-off: Timeout-based allowance reduces moderation coverage but keeps user experience responsive. Alternative: queue all content for async moderation (slower UX).

Potential Improvements for Production

Current State & Demo Notes

What Works Now

Demo Video

Watch technical walkthrough on YouTube

Demonstrates:

Demo/Stub Limitations

None—system is fully production. No features are stubbed or simulated.

Why Certain Design Choices Exist

How This Project Demonstrates My Expertise

Backend Engineering

DevOps & Infrastructure

AI Integration

System Architecture & Design

Tangible Impact

</div>

Engineering Stack

Backend Core

  • Python 3.9+ (asyncio)
  • SQLAlchemy (Async ORM)
  • Pydantic (Validation)
  • aiogram (Bot Framework)

Data & Scaling

  • MySQL (ACID compliant)
  • Connection Pooling
  • Docker (Containerization)
  • Structured Logging

AI Integration

  • OpenAI API
  • Google Gemini
  • Groq (Llama Guard)
  • Custom Fallback Routing

Production Ops

  • GitHub Actions (CI/CD)
  • Environment Management
  • Automated Backups
  • Performance Monitoring

System Impact & Metrics

Scale

500+ active users managed in production environment

Uptime

99.9% system availability through redundant AI layers

Throughput

1,000+ complex AI generations processed daily

Efficiency

Handles 50+ concurrent requests without latency spikes

Repository & Code Review

Engineering Status: Shipped to production. The codebase demonstrates advanced async patterns, database optimization, and secure multi-provider integration.

Access to the private repository is available for technical deep-dives and system architecture discussions.