Backend Ready | IT

🟠Стартовая линия (Request Line) Метод: Определяет тип запроса и действия, которые должен выполнить сервер. Основные методы включают: GET: Запрос на получение данных с сервера. POST: Отправка данных на сервер для обработки (например, форма). PUT: Замена существующего ресурса на сервере. DELETE: Удаление ресурса с сервера. PATCH: Частичное обновление ресурса. URI (Uniform Resource Identifier): Указывает путь к ресурсу на сервере. Версия протокола HTTP: Определяет используемую версию HTTP, например, HTTP/1.1. 🟠Заголовки (Headers) Метаданные, которые предоставляют дополнительную информацию о запросе. Примеры заголовков: Host: Указывает имя хоста и, возможно, номер порта сервера (например, www.example.com). User-Agent: Информация о клиентском приложении, совершающем запрос (например, браузер). Accept: Типы данных, которые клиент готов принять (например, text/html, application/json). Content-Type: Тип данных, передаваемых в теле запроса (например, application/json для JSON данных). Authorization: Информация для аутентификации, если запрос требует авторизации. 🟠Тело запроса (Body) Содержит данные, отправляемые на сервер. Тело запроса используется в методах POST, PUT, PATCH для передачи данных, таких как формы, файлы или JSON-объекты. Для методов GET и DELETE тело запроса обычно не используется. 🚩Зачем нужны эти компоненты 🟠Метод и URI Метод определяет действие, которое клиент хочет выполнить, а URI указывает конкретный ресурс, к которому это действие применяется. Это основа понимания сервером того, что именно клиент запрашивает. 🟠Заголовки Заголовки предоставляют контекст и дополнительную информацию, необходимую для корректной обработки запроса. Они могут содержать данные о клиенте, указывать формат передаваемых данных, управлять кэшированием и аутентификацией. 🟠Тело запроса Тело запроса содержит основное содержание, которое клиент хочет передать на сервер. Например, данные формы, JSON-объекты или файлы. Без тела запроса невозможно передать на сервер данные, которые необходимо обработать.

    
        POST /submit-form HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

name=John+Doe&age=30{}
    

⚙ Backend Ready | #урок

GitHub теперь в Telegram! Самый прогерский канал, где за 10 минут ты научишься: / Пробив по фото и номеру в ТГ // Как взломать вебку подруги /// Мануал по OSINT разведке Подписывайся, нас уже сотни тысяч: >@GitHub

Тебя спрашивают на бэкенд-собесе. Вопрос:

Как бы ты спроектировал распределенную систему cron-планирования, которая гарантирует, что задачи будут запускаться ровно один раз, вовремя, на нескольких нодах, без коллизий и дубликатов?

Как к этому подойти: Начни с базовых требований: • централизованно определять и хранить расписания • несколько scheduler-нод, но в конкретный момент только одна должна триггерить задачу • задачи должны выполняться ровно один раз, даже если ноды рестартуют или падают • поддержка ретраев, backoff и идемпотентных обработчиков • видимость last-run и next-run Архитектура системы: • Control Plane: UI/API для создания cron-задач • кластер scheduler-ов • распределенный локинг (Redis, Zookeeper, Etcd, DynamoDB) • пул воркеров, который выполняет задачи • хранилище результатов и метаданных Гарантия, что задачу триггерит только одна нода: • на каждую задачу используется отдельный распределенный лок • нода, которая захватывает лок, и запускает выполнение • у лока есть TTL, чтобы не виснуть навечно • если нода умерла, другая подберет задачу на следующем тике Как работает планирование: • все scheduler-ноды подгружают cron-описания • каждую секунду каждая нода проверяет, что надо запускать • если задача должна стартовать, нода пробует взять лок • победитель отправляет задачу в пул воркеров Ретраи и ошибки: • у каждой задачи свои правила ретраев (число попыток и backoff) • при ошибке создается событие retry • ретраи тоже проходят через тот же механизм локов • воркер должен быть идемпотентным, чтобы переживать редкие дубликаты Масштабирование воркеров: • воркеры должны быть stateless и масштабироваться горизонтально • задачи — это сообщения с job ID и payload • используется очередь/брокер (Kafka, SQS, RabbitMQ) • планирование отделено от выполнения Консистентность и надежность: • cron-определения хранятся в консистентной базе • scheduler-ноды держат копии в памяти и периодически обновляют • сохраняется история запусков (start, end, статус, ошибка) • можно включить catch-up для пропущенных запусков Обсервабилити: • метрики next_run_at, last_run_at, длительность, успех/ошибка • Prometheus-метрики и трассировка медленных задач • алерты на зависшие задачи и повторные фейлы • UI с инфой, какая нода выполняла какой запуск Как ответить на собесе:

Я бы построил распределенный cron с централизованным управлением расписаниями, несколькими scheduler-нодами и распределенным локом, чтобы задача триггерилась ровно один раз. Выполнение вынесено в пул воркеров, каждый запуск логируется, ретраи координируются через очередь, и система остаётся консистентной даже при падении нод.

⚙ Backend Ready | #собес

☄️В преддверии Нового года айтишник из “Matrix” скупил все курсы топовых IT-школ и выложил 5 ТБ слитых курсов к себе в каналы! 👩‍💻 Python: https://t.me/+kBPlIQ1kpHw0YmQy 👩‍💻 Все ЯП: https://t.me/+pkvOZc3g5gU3YTEy 👩‍💻 Backend: https://t.me/+QRq_LSpodJ80NjE6 📱 Frontend и Web: https://t.me/+jOItOzJamrNhOTIy 👩‍💻 Графика и дизайн: https://t.me/+lxe3X0QQXVk2NWIy Все материалы в закрепе и постоянно пополняются👆

➗ Основные ветки master — стабильные релизы. develop — код, готовящийся к следующему релизу. Рабочие ветки feature/ — новые функции. release/ — подготовка релиза. hotfix/ — срочные исправления. ⸻ ❓ Как используется • feature → делается от develop, возвращается в develop. • release → от develop → тесты → merge в master и develop, тег. • hotfix → от master → исправление → merge в master и develop, тег. ⸻ 🔵 Плюсы Структурированная работа, удобная параллельная разработка, понятные релизы. 🟠 Минусы Сложнее для маленьких проектов, требует дисциплины.

Нормализация баз данных — кратко и по делу ⚙ Backend Ready | #урок