[Backend-розробка · Бази даних · Архітектура ПЗ]
Архітектура бекенда та зберігання даних
Серверна архітектура, на якій тримається платформа: акаунти, сигнали, налаштування, стани, фонові задачі, доступ, звіти й моніторинг — розвиток без переписування.
01Огляд проєкту
Від цього шару залежать усі інші кейси на сайті. Він зберігає користувачів, сигнали, налаштування й стани, запускає фонові процеси, спілкується із зовнішніми API та доставляє інформацію в Telegram і веб-інтерфейси.
Акцент — на контрольованому розвитку: додавати функції та виправляти помилки в системі, де вже багато рухомих частин, із перевіркою кожної зміни до продакшену.
02Інженерна задача
Коли багато підсистем використовують одну базу й працюють паралельно, складними стають узгодженість, обробка збоїв і керування змінами — а не окремі функції.
- A
Зберігати узгодженість стану між діями користувачів і фоновими процесами.
- B
Обробляти некоректні або неповні дані від зовнішніх сервісів.
- C
Планувати фонові операції без накладань і втрати роботи.
- D
Робити кожну важливу подію простежуваною за логами.
03Архітектура рішення
Наведіть або натисніть на етап.
Зовнішні API
Біржі, Telegram, AI-провайдери та інші сервіси.
Моніторинг і журнали подій спостерігають за кожним етапом.
04Основні компоненти
- 01
Модель даних
SQL-таблиці та зв’язки для акаунтів, сигналів, налаштувань, станів та історії подій.
- 02
Сервісний шар
Асинхронні Python-сервіси, що інкапсулюють бізнес-логіку та зовнішні інтеграції.
- 03
Воркери
Фонові процеси для задач за розкладом і тривалих операцій.
- 04
Перевірки цілісності
Валідація вхідних даних та інваріантів перед записом.
- 05
Логування подій
Структуровані логи, що пов’язують дії користувачів і фонову роботу.
- 06
Доставка
Ендпоїнти й повідомлення, що доставляють результати в Telegram і веб-інтерфейси.
05Технологічний стек
Ядро
- Python
- async / await
- aiohttp
Дані
- SQL
- SQLite
- Data modeling
Експлуатація
- Linux VPS
- Background processes
- Structured logging
06Інтерактивна демонстрація
Шлях запиту через бекенд
ІлюстраціяІлюстративне демо. Надішліть запит через шари й додайте збій, щоб побачити, як помилки обробляються та логуються.
$ tail -f app.log
Моніторинг
- оброблено
- 0
- дедупліковано
- 0
- повторів
- 0
- відхилено (невалідно)
- 0
- збій → алерт
- 0
07Інженерні рішення
- 01
Розвивати, а не переписувати
Зміни вносяться поступово за чіткими межами, перевіряються й лише потім розширюються.
- 02
Перевіряти до збереження
Погані дані зупиняються на шарі логіки, тож база лишається надійним джерелом істини.
- 03
Ідемпотентна фонова робота
Воркери можна безпечно перезапустити після переривання без дублювання ефектів.
- 04
Логи як частина продукту
Структуровані, пов’язані логи роблять поведінку в продакшені зрозумілою.
08Надійність і тестування
- Перевірка змін відносно поточної поведінки до деплою.
- Дедуплікація подій та ідемпотентна обробка.
- Обробка помилок навколо кожної зовнішньої залежності.
- Перевірка фактичної поведінки в продакшені після деплою.
09Приклад коду
import sqlite3
from datetime import datetime, timezone
def process_event(db: sqlite3.Connection, event_id: str, source: str, kind: str) -> bool:
"""Returns True if processed now, False if it was already handled."""
try:
with db: # one transaction: mark + apply, or neither
db.execute(
"INSERT INTO processed_events (event_id, source, event_type, processed_at) "
"VALUES (?, ?, ?, ?)",
(event_id, source, kind, datetime.now(timezone.utc).isoformat()),
)
apply_side_effects(db, event_id, kind)
return True
except sqlite3.IntegrityError:
return False # duplicate delivery — safe to ignore
def apply_side_effects(db: sqlite3.Connection, event_id: str, kind: str) -> None:
...Ілюстрація Ілюстративний інженерний приклад — ідемпотентна обробка подій у SQLite.
Вихідний код продукту закритий. Приклади показують інженерний підхід, а не внутрішню логіку. Більше — в Engineering Lab.
10Можливий розвиток
- Перехід на PostgreSQL за потреби вищої конкурентності запису.
- Ендпоїнт метрик для глибини черги та тривалості задач.
- Контрактні тести для ендпоїнтів, які використовують інтерфейси.