Skip to content

Instantly share code, notes, and snippets.

@vedmichv
Last active June 24, 2025 21:07
Show Gist options
  • Save vedmichv/35a8c5fcfe3ca98c3b39b96cf5dce7ed to your computer and use it in GitHub Desktop.
Save vedmichv/35a8c5fcfe3ca98c3b39b96cf5dce7ed to your computer and use it in GitHub Desktop.
PRD - DKT News Telegram Bot

DKT News Bot Product Requirements Document

1. Introduction

This Product Requirements Document (PRD) defines the specifications for the DevOps Kitchen Talks (DKT) News Bot, a Telegram-based application designed to streamline the collection, processing, and sharing of DevOps-related news within the community. This document serves as the authoritative source for all product features, technical requirements, and implementation guidelines for the development team.

The DKT News Bot leverages artificial intelligence to provide automated content summarization, enabling community members to quickly digest relevant industry news without information overload. This PRD outlines the complete product vision, user requirements, and technical specifications necessary to deliver a production-ready solution.

2. Product overview

The DKT News Bot is a sophisticated Telegram bot that transforms how the DevOps community discovers and shares technical news. By combining web scraping technologies with AWS Bedrock's Claude AI models, the bot automatically processes submitted URLs to generate concise summaries in two formats: short (300 characters) for quick scanning and long (500 characters) for detailed insights.

The bot operates within the Telegram ecosystem, providing a familiar interface for users while offering powerful backend processing capabilities. Content is organized into episodes—thematic collections that group related articles for easy browsing and reference. A built-in engagement system allows users to react to articles with likes or dislikes, helping surface the most valuable content for the community.

Key differentiators include:

  • Dual-language support with Russian as the primary user interface language
  • Microservices architecture enabling independent scaling of components
  • Multi-tier content extraction with automatic fallback mechanisms
  • Real-time processing with sub-30-second content summarization
  • Administrative tools for content curation and episode management

3. Goals and objectives

3.1 Primary goals

  1. Simplify knowledge sharing: Enable DevOps professionals to share relevant articles with minimal effort through simple URL submission
  2. Reduce information overload: Provide AI-generated summaries that distill key insights from lengthy technical articles
  3. Foster community engagement: Create an interactive platform where members can discover, share, and rate DevOps content
  4. Ensure content quality: Leverage advanced AI models to maintain high-quality, accurate summarizations

3.2 Business objectives

  • Achieve 50+ daily active users within 3 months of launch
  • Process 95%+ of submitted URLs successfully
  • Maintain <2 second response time for user commands
  • Achieve >80% positive reaction ratio on shared content

3.3 Technical objectives

  • Support 100+ concurrent users without performance degradation
  • Implement horizontal scaling for all critical services
  • Ensure 99.5% uptime excluding planned maintenance
  • Provide comprehensive monitoring and alerting for all services

4. Target audience

4.1 Primary users

DevOps engineers and practitioners (80% of user base)

  • Age: 25-40 years
  • Technical proficiency: Intermediate to advanced
  • Daily news consumption: 15-30 minutes
  • Primary device: Mobile (70%), Desktop (30%)
  • Key needs: Stay updated on tools, best practices, and industry trends

4.2 Secondary users

Community administrators and moderators (20% of user base)

  • Age: 30-45 years
  • Technical proficiency: Advanced to expert
  • Weekly curation time: 1-2 hours
  • Primary device: Desktop (60%), Mobile (40%)
  • Key needs: Maintain content quality, organize episodes, track engagement

4.3 User journey mapping

4.3.1 Content submission journey

Discovery → Evaluation → Submission → Processing → Confirmation → Engagement
    ↓           ↓           ↓           ↓            ↓              ↓
Find article → Worth     → Copy URL   → Bot        → View         → React/Share
on site        sharing?    and send     processes    summary
                          to bot       content

Touchpoints:

  • External news sites (discovery)
  • Telegram app (submission)
  • Bot notifications (processing updates)
  • Community channels (engagement)

4.3.2 Content consumption journey

Intent → Access → Browse → Select → Consume → Engage → Explore
   ↓       ↓        ↓        ↓        ↓         ↓        ↓
Want    → Open   → Use    → Choose → Read    → Vote   → Click
news      bot     /news    episode   summary   👍/👎    link

Touchpoints:

  • Telegram notifications
  • Bot interface
  • Episode browsing
  • External article links
  • Reaction system

4.4 User characteristics

  • Language preference: Russian for all user interactions
  • Time-constrained professionals seeking efficient information consumption
  • Active Telegram users familiar with bot interactions
  • Value peer-curated content over algorithmic recommendations

5. Features and requirements

5.1 Core features

5.1.1 Content submission and processing

  • URL validation and normalization
  • Duplicate detection across all episodes
  • Multi-tier content extraction (Scrapy → crawl4ai → BeautifulSoup)
  • AI-powered summarization using AWS Bedrock Claude models
  • Automatic episode assignment to active episode

5.1.2 Content discovery and consumption

  • Episode-based content organization
  • Paginated news browsing (3-4 items per page)
  • Short summaries for quick scanning
  • Direct links to original articles
  • Real-time reaction system (like/dislike)

5.1.3 Administrative functions

  • Episode creation and management
  • Content moderation (delete, move, pin)
  • Extended summaries for detailed review
  • Episode locking to prevent new submissions
  • Bulk operations for content management

5.2 Functional requirements

Requirement ID Feature Description Priority
FR-001 URL Submission Accept and validate HTTP/HTTPS URLs High
FR-002 AI Summarization Generate 300-char and 500-char summaries High
FR-003 Episode Management Create, activate, and lock episodes High
FR-004 Reaction System Like/dislike with toggle behavior Medium
FR-005 Pagination Navigate through news items Medium
FR-006 Duplicate Detection Prevent reprocessing of URLs High
FR-007 Admin Commands Full content lifecycle management High
FR-008 Russian Interface All user messages in Russian High
FR-009 Message Formatting Use Telegram MarkdownV2/HTML High

5.3 Non-functional requirements

Requirement ID Category Requirement Target
NFR-001 Performance Bot command response time <2 seconds
NFR-002 Performance Content processing time <30 seconds
NFR-003 Scalability Concurrent users 100+
NFR-004 Reliability System uptime 99.5%
NFR-005 Usability Error message clarity 100% actionable
NFR-006 Security Admin authentication Telegram ID-based
NFR-007 Presentation Message formatting MarkdownV2/HTML

6. User stories and acceptance criteria

6.1 Authentication and access control

ST-101: User registration

  • As a new user, I want to register with the bot so that I can start submitting and viewing news
  • Acceptance criteria:
    • User sends /start command
    • Bot responds with welcome message in Russian
    • User is automatically registered in the database
    • User receives confirmation of successful registration

ST-102: Admin authentication

  • As an administrator, I want secure access to admin commands so that only authorized users can manage content
  • Acceptance criteria:
    • Admin Telegram IDs are preconfigured in the system
    • Non-admin users receive "unauthorized" message for admin commands
    • Admin status is verified for each admin command execution
    • Authentication checks complete in <100ms

6.2 Content submission

ST-201: Submit news URL

  • As a user, I want to submit a news article URL so that it can be processed and shared with the community
  • Acceptance criteria:
    • User sends a valid HTTP/HTTPS URL
    • Bot acknowledges receipt within 2 seconds
    • Processing notification is displayed
    • Summary is returned within 30 seconds
    • Article is added to the active episode

ST-202: Handle invalid URL

  • As a user, I want clear feedback when submitting an invalid URL so that I can correct my input
  • Acceptance criteria:
    • Bot validates URL format
    • Invalid URLs trigger error message in Russian
    • Error message suggests correct format
    • No processing task is created

ST-203: Detect duplicate submissions

  • As a user, I want to know if an article has already been submitted so that I don't create duplicates
  • Acceptance criteria:
    • System checks URL against all existing articles
    • Duplicate URLs return existing summary
    • User is notified that article already exists
    • Original submission details are provided

6.3 Content discovery

ST-301: View current episode news

  • As a user, I want to view news from the current episode so that I can discover new content
  • Acceptance criteria:
    • User sends /news command
    • Bot displays current episode title
    • First page of news items is shown (3-4 items)
    • Each item includes title and short summary
    • Pagination buttons are displayed

ST-302: Navigate between pages

  • As a user, I want to navigate through multiple pages of news so that I can see all available content
  • Acceptance criteria:
    • Navigation buttons (⬅️ ➡️) are displayed
    • Page indicator shows current position
    • Navigation updates within 2 seconds
    • First/last page disables appropriate button

ST-303: View specific episode

  • As a user, I want to view news from a specific episode so that I can access historical content
  • Acceptance criteria:
    • User sends /news [episode_number]
    • Bot validates episode exists
    • Requested episode news is displayed
    • Error message for non-existent episodes

ST-304: List all episodes

  • As a user, I want to see all available episodes so that I can choose which to explore
  • Acceptance criteria:
    • User sends /episodes command
    • Bot displays numbered list of episodes
    • Each episode shows title and article count
    • Active episode is clearly marked

6.4 Engagement features

ST-401: React to articles

  • As a user, I want to like or dislike articles so that I can provide feedback on content quality
  • Acceptance criteria:
    • Like/dislike buttons appear with each article
    • Clicking updates reaction count in real-time
    • User can change their reaction
    • One reaction per user per article

ST-402: View reaction counts

  • As a user, I want to see reaction counts so that I can gauge community sentiment
  • Acceptance criteria:
    • Current like/dislike counts are displayed
    • Counts update without page refresh
    • Zero counts display as "0"
    • Format: "👍 12 | 👎 3"

6.5 Administrative functions

ST-501: Create new episode

  • As an admin, I want to create new episodes so that I can organize content thematically
  • Acceptance criteria:
    • Admin sends /new_episode <title>
    • Episode is created with unique ID
    • Confirmation message includes episode number
    • Episode is set as inactive by default

ST-502: Activate episode

  • As an admin, I want to activate an episode so that new submissions go to the correct collection
  • Acceptance criteria:
    • Admin sends /set_active <episode_number>
    • Previous active episode is deactivated
    • New episode becomes active
    • All new submissions go to active episode

ST-503: Delete news item

  • As an admin, I want to delete inappropriate content so that I can maintain quality standards
  • Acceptance criteria:
    • Admin sends /delete_news <news_id>
    • News item is marked as deleted
    • Item no longer appears in user views
    • Deletion is logged for audit

ST-504: Move news between episodes

  • As an admin, I want to move news items so that I can reorganize content
  • Acceptance criteria:
    • Admin sends /move_news <news_id> <target_episode>
    • News item is reassigned to new episode
    • Item appears in target episode
    • Original episode is updated

ST-505: View extended summaries

  • As an admin, I want to see detailed summaries so that I can better evaluate content
  • Acceptance criteria:
    • Admin sends /news_long or /long_summary <news_id>
    • 500-character summary is displayed
    • Additional metadata is shown
    • Response time <2 seconds

6.6 Database operations

ST-601: Store user data

  • As the system, I need to store user information so that I can track submissions and reactions
  • Acceptance criteria:
    • User table stores telegram_id, username, registration_date
    • Unique constraint on telegram_id
    • Indexes on frequently queried fields
    • Support for 10,000+ users

ST-602: Store news articles

  • As the system, I need to store article data so that I can serve content efficiently
  • Acceptance criteria:
    • News table includes all required fields
    • URL uniqueness is enforced
    • Full-text search on summaries
    • Efficient pagination queries

ST-603: Track reactions

  • As the system, I need to store user reactions so that I can display accurate counts
  • Acceptance criteria:
    • Reaction table links users to news items
    • Composite unique constraint (user_id, news_id)
    • Aggregated counts are queryable
    • Support for updates/deletes

6.7 Error handling

ST-701: Handle extraction failures

  • As a user, I want clear feedback when article extraction fails so that I understand what went wrong
  • Acceptance criteria:
    • Extraction errors trigger specific messages
    • Bot suggests alternatives (try later, check URL)
    • Failed URLs are logged for debugging
    • User can retry submission

ST-702: Handle AI service errors

  • As a user, I want the system to gracefully handle AI service failures so that my experience isn't disrupted
  • Acceptance criteria:
    • AI errors trigger fallback to alternate models
    • If all models fail, user receives notification
    • Failed tasks are queued for retry
    • Maximum 3 retry attempts

ST-703: Handle database errors

  • As the system, I need to handle database failures so that data integrity is maintained
  • Acceptance criteria:
    • Connection failures trigger reconnection attempts
    • Transactions rollback on errors
    • Users receive "temporary error" message
    • Critical errors alert administrators

6.8 Message formatting

ST-801: Format messages with Telegram markup

  • As a user, I want to see well-formatted messages so that content is easy to read and navigate
  • Acceptance criteria:
    • All messages use MarkdownV2 or HTML formatting
    • Special characters are properly escaped
    • Links are clickable inline elements
    • Summaries use expandable blockquotes

ST-802: Display rich content formatting

  • As a user, I want to see visual hierarchy in messages so that I can quickly scan content
  • Acceptance criteria:
    • Titles use bold formatting
    • Summaries use blockquote formatting
    • Metadata uses italic formatting
    • Code snippets use monospace

7. Technical requirements / stack

7.1 Core technology stack

Component Technology Version Justification
Programming Language Python 3.13 Modern async support, type hints
Package Manager UV Latest Fast dependency resolution
Web Framework FastAPI 0.115.6 High performance, automatic documentation
Bot Framework python-telegram-bot 22.1.0 Comprehensive Telegram API coverage
Database PostgreSQL 15 JSONB support, proven reliability
ORM SQLAlchemy 2.0.41 Async support, robust querying
Task Queue Celery 5.3.6 Mature distributed task processing
Message Broker Redis 7+ Low latency, simple deployment
Web Scraping Scrapy 2.12.0 Industrial-strength scraping
AI Scraping crawl4ai 0.6.3 JavaScript rendering support

7.1.1 Core technologies

  • Programming language: Python 3.13
  • Package manager: UV (latest version)
  • Web framework: FastAPI 0.115.6
  • ASGI server: Uvicorn 0.34.0
  • Bot framework: python-telegram-bot 22.1.0
  • Database: PostgreSQL 15
  • ORM: SQLAlchemy 2.0.41
  • Task queue: Celery 5.3.6
  • Message broker: Redis 7+
  • Web scraping: Scrapy 2.12.0, crawl4ai 0.6.3

7.1.2 AI and external services

  • Primary AI service: AWS Bedrock
  • AI models: Claude 4 Sonnet, Claude 3.5 Sonnet, Amazon Nova Pro
  • External APIs: Telegram Bot API
  • Monitoring: Prometheus, Grafana
  • Logging: Structured logging with JSON format

7.1.3 Development and deployment

  • Containerization: Docker 24.0+
  • Orchestration: Docker Compose 2.20+
  • Code formatting: Black 23.0+
  • Linting: Ruff 0.1.0+
  • Testing: pytest 7.4+
  • Git hooks: pre-commit 3.5+
  • API testing: Postman/Insomnia

7.2 Architecture requirements

7.2.1 Service architecture

┌─────────────────────────────────────────────────────────────────────┐
│                        User Layer (Telegram)                        │
├─────────────────────────────────────────────────────────────────────┤
│  ┌─────────────────────────────────────────────────────────┐        │
│  │              Telegram Bot API (Webhook/Polling)          │      │
│  └────────────────────────┬────────────────────────────────┘       │
├───────────────────────────┼──────────────────────────────────────────┤
│                    Application Layer                                 │
├─────────────────────────────────────────────────────────────────────┤
│  ┌────────────────────────┴─────────────────────────────────┐       │
│  │                  FastAPI Application                      │       │
│  │  ┌─────────────┐  ┌──────────────┐  ┌────────────────┐  │       │
│  │  │  Telegram   │  │   Command    │  │    Content     │  │       │
│  │  │  Handler    │  │   Router     │  │   Processor    │  │       │
│  │  └─────────────┘  └──────────────┘  └────────────────┘  │       │
│  └────────────────────────┬─────────────────────────────────┘       │
├───────────────────────────┼──────────────────────────────────────────┤
│                    Processing Layer                                  │
├─────────────────────────────────────────────────────────────────────┤
│  ┌────────────────────────┴─────────────────────────────────┐       │
│  │                    Celery Workers                         │       │
│  │  ┌─────────────┐  ┌──────────────┐  ┌────────────────┐  │       │
│  │  │   Scraper   │  │     AI       │  │   Database     │  │       │
│  │  │   Worker    │  │  Summarizer  │  │    Worker      │  │       │
│  │  └─────────────┘  └──────────────┘  └────────────────┘  │       │
│  └────────────────────────┬─────────────────────────────────┘       │
├───────────────────────────┼──────────────────────────────────────────┤
│                     Data Layer                                       │
├─────────────────────────────────────────────────────────────────────┤
│  ┌────────────────┐       │       ┌─────────────────────────┐       │
│  │     Redis      │───────┴───────│     PostgreSQL 15       │       │
│  │  (Queue/Cache) │               │   (Primary Database)    │       │
│  └────────────────┘               └─────────────────────────┘       │
└──────────────────────────────────────────────────────────────────────┘

7.2.2 Service definitions

FastAPI Application Service:

  • Purpose: HTTP API and Telegram webhook handler
  • Endpoints: Health check, webhook, admin API
  • Dependencies: PostgreSQL, Redis
  • Scaling: Horizontal (2-10 instances)

Telegram Bot Service:

  • Purpose: Handle Telegram updates via polling/webhook
  • Commands: User and admin command processing
  • Dependencies: PostgreSQL, Redis, Celery
  • Scaling: Single instance (polling) or horizontal (webhook)

Celery Worker Service:

  • Purpose: Asynchronous task processing
  • Queues: high_priority, scraping, ai_summary, default
  • Dependencies: PostgreSQL, Redis, AWS Bedrock
  • Scaling: Horizontal by queue type

Celery Beat Service:

  • Purpose: Scheduled task execution
  • Tasks: Cleanup, statistics, health checks
  • Dependencies: Redis, PostgreSQL
  • Scaling: Single instance

7.3 AI/ML services

Service Model Purpose Fallback Strategy
Primary AWS Bedrock Claude 4 Sonnet Content summarization Automatic failover
Secondary AWS Bedrock Claude 3.5 Sonnet Backup summarization When primary unavailable
Tertiary AWS Bedrock Amazon Nova Pro Cost-optimized option For high-volume periods

7.4 Infrastructure requirements

  • Containerization: Docker 24.0+ with Docker Compose 2.20+
  • Container Resources:
    • FastAPI: 512MB-1GB RAM, 0.5-1 CPU
    • Bot Service: 512MB RAM, 0.5 CPU
    • Celery Workers: 1-2GB RAM, 1-2 CPU
    • PostgreSQL: 2-4GB RAM, 2 CPU
    • Redis: 512MB RAM, 0.5 CPU

7.5 Monitoring and observability

  • Application metrics: Prometheus + Grafana
  • Log aggregation: ELK stack or CloudWatch
  • Error tracking: Sentry
  • Uptime monitoring: UptimeRobot or Pingdom

8. Design and user interface

8.1 Interaction design principles

  1. Conversational UI: All interactions follow natural conversation patterns
  2. Immediate feedback: Every action receives acknowledgment within 2 seconds
  3. Progressive disclosure: Complex features revealed through admin commands
  4. Error prevention: Validate input before processing
  5. Russian-first: All user-facing text in Russian language

8.2 Command structure

8.2.1 User commands

/start - Начать работу с ботом
/help - Показать доступные команды
/news [номер_эпизода] - Просмотреть новости
/episodes - Список всех эпизодов
/status - Информация об активном эпизоде
/myid - Получить ваш Telegram ID

8.2.2 Message templates

Welcome message:

Добро пожаловать в DKT News Bot! 🚀

Я помогу вам быть в курсе новостей DevOps.
Отправьте мне ссылку на статью, и я создам краткое содержание.

Используйте /help для просмотра команд.

URL processing:

📝 Обрабатываю вашу ссылку...
Это может занять до 30 секунд.

Summary display:

📰 {title}

{short_summary}

🔗 Читать полностью
👍 0 | 👎 0

Страница {current} из {total}
[⬅️ Назад] [Вперед ➡️]

8.3 Interactive elements

8.3.1 Inline keyboards

  • Reaction buttons: Two-button row (👍 Like | 👎 Dislike)
  • Navigation buttons: Two-button row (⬅️ Previous | Next ➡️)
  • URL button: Single button linking to original article

8.3.2 Button behavior

  • Toggle reactions: Clicking again removes reaction
  • Disabled navigation: Gray out when at first/last page
  • Loading states: Show "..." during updates

8.4 Message formatting specifications

8.4.1 Formatting standards

All messages sent to Telegram must use either MarkdownV2 or HTML formatting. HTML is preferred for complex layouts, especially those containing expandable content.

8.4.2 MarkdownV2 syntax reference

Element Syntax Example
Bold *text* *важная информация*
Italic _text_ _примечание_
Underline __text__ __подчеркнутый текст__
Strikethrough ~text~ ~устаревшая информация~
Spoiler ||text|| ||скрытый текст||
Inline code `code` `docker run`
Pre-formatted block ```text``` ```configuration```
Inline URL [text](url) [Читать статью](https://example.com)
Block quote >text >Цитата из статьи

Special character escaping: The following characters must be escaped with \: _*[]()~ >#+-=|{}.!

8.4.3 HTML formatting (preferred)

For summary display, HTML formatting with expandable blockquotes is recommended:

<b>📰 {title}</b>

<blockquote expandable>
{short_summary}
</blockquote>

<a href="{url}">🔗 Читать полностью</a>

👍 {likes} | 👎 {dislikes}

8.4.4 Formatted message examples

News item display (HTML):

<b>📰 Kubernetes 1.30: Что нового в последнем релизе</b>

<blockquote expandable>
Kubernetes 1.30 представляет улучшенную поддержку multi-tenancy, 
новые возможности для работы с volumes и значительные улучшения 
производительности kube-apiserver...
</blockquote>

<a href="https://kubernetes.io/blog/2024/04/17/kubernetes-1-30-release/">🔗 Читать полностью</a>

👍 15 | 👎 2

Episode listing (MarkdownV2):

*📚 Доступные эпизоды:*

*Episode 1:* _Cloud Native Security_ \(15 статей\)
*Episode 2:* _Kubernetes Best Practices_ \(23 статьи\)
*Episode 3:* _CI/CD Automation_ \(19 статей\)_Используйте_ `/news [номер]` _для просмотра_

Error message (MarkdownV2):

*Ошибка обработки ссылки*

_Не удалось извлечь содержимое статьи\._

*Возможные причины:*
• Сайт временно недоступен
• Страница требует авторизацию
• Неподдерживаемый формат контента

_Попробуйте отправить ссылку позже или проверьте её доступность\._

Processing notification (HTML):

<b>Обрабатываю вашу ссылку...</b>

<i>Анализирую содержимое статьи с помощью AI</i>
<i>Это может занять до 30 секунд</i>

8.5 Error messages

Error Type User Message (Russian) Admin Context Format
Invalid URL "❌ Пожалуйста, отправьте корректную ссылку (http:// или https://)" Log invalid format MarkdownV2
Extraction Failed "⚠️ Не удалось загрузить статью. Попробуйте позже." Log site and error HTML
AI Error "🤖 Временная проблема с AI. Попробуем другую модель..." Fallback activated HTML
Database Error "🔧 Технические работы. Попробуйте через несколько минут." Alert administrators MarkdownV2

8.6 Visual hierarchy

  1. Episode title: Bold, prominent positioning
  2. Article title: Medium weight, clickable appearance
  3. Summary text: Regular weight, high readability
  4. Metadata: Smaller, deemphasized (reactions, pagination)
  5. Action buttons: High contrast, clear boundaries

8.7 Accessibility considerations

  • Keyboard navigation: All features accessible via text commands
  • Screen reader compatibility: Structured message format
  • High contrast: Clear button labels and separators
  • Consistent layout: Predictable element positioning
  • Proper markup: Semantic HTML/Markdown usage
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment