System design

В ответ на пост Парсерам быть или не быть? Давайте сегодня вместе разберём данный кейс. Начнём с общей HLD схемы. Основные внутренние компоненты: — Пользовательский интерфейс (UI): Предоставляет интерфейс для настройки и управления парсерами. — Планировщик задач (Scheduler): Отвечает за расписание и запуск парсеров. — Система выполнения парсеров (Executor): Запускает парсеры в контейнерах. — Хранилище данных (Data Storage): Сохраняет собранные текстовые данные. — Мониторинг и логирование (Monitoring & Logging): Отслеживает работу системы и парсеров. Внешние компоненты: — ML dev: Получают доступ к данным для дальнейшего анализа. — Администраторы: Через UI управляют работой парсеров — Web: ресурсы для парсинга Есть идеи, как можно улучшить схему на этом этапе? Какой стек будем выбирать для каждого из узлов? 🤔 ЛСА | Лайфстайл айтишника

Все мы писали парсеры.. Приступим к system design  Нужно спроектировать систему, которая будет периодически запускать парсеры на разных языках и сохранять данные, которые в дальнейшем будет забирать ML команда для дальнейшей обработки. Управление парсерами должно быть гибким, с возможностью настройки периодичности и ручного запуска. Обсуждаем решение в комментариях к посту, а рисовать можно в draw.io https://drive.google.com/file/d/1NXkfZltpnxNJprKgSPPhiw36lAMg5ioM/view?usp=sharing  (если возникнут трудности с подключением, пишите). Допущения: * Используемые языки для парсеров: Python, R, JS, PHP. * Один парсер может запускаться одновременно во множестве инстансов, чтобы обрабатывать в параллель множество страниц конкретного сайта. * Парсеры могут работать продолжительное время, вплоть до нескольких часов. * Общее количество парсеров не превышает 1000. * Парсеры собирают только текстовые данные. * Объём ежедневно собираемых данных — до 10Gb. * Данные хранятся в течение 3 лет. Какие технологии и подходы вы бы выбрали для реализации такой системы? Как вы организуете хранение данных, управление нагрузкой и мониторинг работы парсеров? Как обеспечить гибкость в настройке периодичности и ручного запуска? ЛСА | Лайфстайл айтишника

Секция system design Хотите прокачать свой навык прохождения system design или посмотреть, как это делают другие? Тогда читаем дальше😉 Если вы будете проходить собеседование на позицию senior dev и выше в какую-нибудь BigTech компанию, то с большой вероятностью у вас будет секция system design. Что такое system design? Это процесс проектирования системы, который включает в себя анализ требований, определение компонентов, их взаимодействие и выбор технологий для реализации. Саму секцию можно разделить на несколько этапов: сбор и анализ требований, разработка высокоуровневой архитектуры, детализация компонентов и взаимодействий, а также оценка рисков и возможностей масштабирования. Проходили подобные секции? Сегодня предлагаю потренировать свой скилл или даже научиться в прохождении данного части собеседования. Но формат будет у нас нестандартный, и вот как предлагаю провести его: 1. В 15:00 я выложу задачу отдельным постом. 2. В комментариях к посту я буду модерировать процесс и выступать стейкхолдером, а также направлять и помогать двигаться в нужном направлении. 3. Чем больше разных предложений и вопросов будет, тем интереснее будет получаться :) Поставьте реакцию, если готовы поучаствовать. От количества заинтересованных подберу более интересную или более простую задачу. ЛСА | Лайфстайл айтишника

Идемпотентность — любимый вопрос на собеседованиях В продолжение вчерашнего кейса, как в итоге решили проблему: Когда клиент нажимает "Оплатить", он отправляет уникальный код (например, ABC123 или UUID) вместе с запросом на сервер. 1. Первый запрос: Сервер видит новый код ABC123, выполняет оплату, сохраняет результат вместе с кодом. 2. Повторный запрос: Сервер видит тот же код ABC123, возвращает сохраненный результат, не проводя оплату повторно. Что получили: - Отсутствие двойных списаний: запросы с одним кодом обрабатываются только один раз. - Экономия ресурсов: сервер не дублирует операции и не стучится во внешние интеграции. - Удовлетворённость клиента: защита от случайных повторных оплат. Как часто вы или у вас спрашивают на собеседовании про идемпотентность? ЛСА | Лайфстайл айтишника

Кейс: двойная оплата при плохом интернете В интернет-магазине клиенты иногда сталкивались с двойным списанием при оплате. Если после нажатия кнопки "Оплатить" связь прерывалась, пользователь не получал подтверждения и нажимал кнопку снова. Сервер обрабатывал каждый запрос отдельно, списывая деньги дважды. После пары быстрых фриланс правок в коде появились следующие конструкции: 1. (На фронте) Блокировка кнопки после нажатия: предотвращает повторные клики, но мешает повторить попытку при сбое. 2. (На беке) Отслеживание времени: игнорирование запросов, поступающих в короткий интервал, но это ненадежно при легитимных повторных попытках. Как думаете, как можно было бы ещё закостылить решение? Позже в комментариях напишу, как в итоге решили проблему. ЛСА | Лайфстайл айтишника