Эфир по System Design

🔍 Основные тезисы: • Системный дизайн — не про создание YouTube с нуля, а про умение подходить к архитектуре решений адекватно: понимать, зачем ты проектируешь, какие есть ограничения, сколько пользователей и как это будет масштабироваться. • Неправильный подход — сразу делать «миллиард пользователей и микросервисы». • Правильный подход — начать с MVP, понимать, что будет меняться, где узкие места, и проектировать с возможностью постепенного роста. ⸻ 🧪 Пример с телеграм-ботом: • Сделан за 2 часа, с SQLite под капотом, без вебхуков (используется long polling). • Простая реализация, которая работает, справляется со своей задачей. Когда нагрузка вырастет — заменят SQLite на PostgreSQL. • Главный месседж: если знаешь, где слабые места, это окей — мониторь и улучшай по мере необходимости. ⸻ 📈 Скейлинг и автоскейлинг: • Что такое горизонтальное масштабирование (новые инстансы). • Как определить, когда надо скейлиться — метрики (CPU, кол-во соединений). • Примеры настройки автоскейлинга на AWS. ⸻ 💬 Обсуждение API и архитектуры: • Клиент-серверная модель: браузер — клиент, сервер — отвечает. • API — это контракт взаимодействия, желательно публичный и документированный. • SQLite хорош для простых приложений, но не для больших нагрузок. ⸻ 🧵 Асинхронность, очереди, шины: • Асинхронная обработка запроса: клиент отправил — сервер положил задачу в очередь. • Уведомление о завершении задачи — через почту, пуш, или API polling. • Шины сообщений (RabbitMQ, Kafka)...