Когда в вакансии пишут «опыт работы с высоконагруженными приложениями», что это значит? Это про миллионы запросов в секунду, как у соцсетей, или про сложные аналитические вычисления, как у систем отчетности?
На самом деле, здесь речь может идти о двух совершенно разных типах нагрузки: OLTP и OLAP.
Разберемся, чем они отличаются.
Это транзакционная нагрузка. То, о чем думают большинство людей, когда слышат словосочетание "высоконагруженное приложение".
Такая нагрузка подразумевает очень много не сложных операций.
На примере соц. сетей это могут быть - получение ленты подписок, получение всех диалогов пользователя, получение списка друзей, списка комментариев к записи, и так далее.
Выполнить одну такую операцию очень просто, но поддерживать доступность сервиса, когда таких запросов десятки тысяч в секунду - уже сложная задача.
Здесь пригодится знание кэшей, шардирования БД и скейлинга stateless сервисов.
Аналитическая нагрузка - полная противоположность. Самих операций очень мало, вплоть до 2-3 запросов в день, но сами запросы очень тяжелые.
Пример такой операции - анализ трат клиентов, выявление трендов, поиск по каким-то условиям, агрегация большого объема данных, прогноз спроса на товары на основе истории продаж за последние 5 лет.
Если OLTP запросы выполняются практически мгновенно, обработка OLAP запросов может занимать часы. В таком случае обычно используют асинхронный алгоритм.
Пользователь получает в ответ не результат, а id операции, которая запланирована к выполнению. С помощью этого id он может узнать статус операции, а когда выполнение закончится, получить итоговый результат.
Для такой нагрузки также стоит хорошо знать виды баз данных, партиционирование и шардинг, а также умение разбивать большую задачу на множество подзадач, которые можно выполнять независимо, а потом обрабатывать их результаты. Один из алгоритмов, которые можно применять - Map/Reduce.
Map/Reduce — это подход, который позволяет разбивать сложные задачи на более простые шаги: сначала обработка данных (Map), затем их объединение (Reduce). Такой подход активно используется в системах вроде Hadoop или Spark.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3🤯2
Гитхаб прислал уведомление, что кто-то запушил 0 коммитов
Это и есть тот самый призрачный разработчик? 👀
Это и есть тот самый призрачный разработчик? 👀
📦 Transactional Outbox (TO) – кратко
#длясобесов #архитектура
TO — паттерн для гарантированной передачи событий (например, в Kafka или другой брокер сообщений) из микросервиса, без риска потери данных, даже при сбоях.
🔥 Какую проблему решаем?
Микросервис сохраняет запись в свою базу данных и пытается сразу отправить событие в брокер.
Если запись успешно сохранена, а отправка в брокер не удалась (например, из-за сбоя сети), возникает рассинхронизация (данные в БД есть, события в Kafka нет).
🛠️ Как работает TO?
1️⃣ Сохраняем данные и событие в одной транзакции в таблицу
2️⃣ Фоновый процесс читает события с sent = false, блокируя их
3️⃣ Отправляет событие в брокер.
4️⃣ В случае успеха — помечает как отправленное и закрывает транзакцию
🧩 Ключевые моменты
Транзакционная целостность: запись данных и события в БД — в рамках одной транзакции (ACID).
Фоновый процесс может быть развернут в нескольких инстансах для масштабирования.
События должны иметь поле, по которому можно определить что событие одно и то же (такое поле называется ключ идемпотентности). Они нужны чтобы повторная доставка не привела к дублированию.
Потребителям нужно использовать дедубликацию на основе ключа идемпотентности.
🧠 Вопросы, которые могут задать
Почему не отправлять событие напрямую в брокер в той же транзакции?
Т.к. брокер и БД не поддерживают распределённые транзакции, риск рассинхронизации если отправка будет успешна а транзакция не закроется.
Как работает идемпотентность в TO?
Ключи сообщений (например, message_id), которые позволяют потребителю игнорировать дубликаты.
Какие таблицы участвуют?
Основная таблица (например, orders) + таблица outbox.
Например
💡 Основные плюсы TO:
✅ Минимизирует риск потери данных.
✅ Поддержка высокой доступности и отказоустойчивости.
✅ Простая реализация в рамках одного микросервиса.
#длясобесов #архитектура
TO — паттерн для гарантированной передачи событий (например, в Kafka или другой брокер сообщений) из микросервиса, без риска потери данных, даже при сбоях.
🔥 Какую проблему решаем?
Микросервис сохраняет запись в свою базу данных и пытается сразу отправить событие в брокер.
Если запись успешно сохранена, а отправка в брокер не удалась (например, из-за сбоя сети), возникает рассинхронизация (данные в БД есть, события в Kafka нет).
🛠️ Как работает TO?
1️⃣ Сохраняем данные и событие в одной транзакции в таблицу
outbox.2️⃣ Фоновый процесс читает события с sent = false, блокируя их
BEGIN;
SELECT id, payload
FROM outbox
WHERE sent = false
FOR UPDATE SKIP LOCKED
LIMIT 10;
-- Далее вы обрабатываете выбранные записи в приложении, например, отправляете в Kafka
-- После успешной отправки можно обновить статус:
-- UPDATE outbox SET sent = true WHERE id IN (...);
COMMIT;
3️⃣ Отправляет событие в брокер.
4️⃣ В случае успеха — помечает как отправленное и закрывает транзакцию
🧩 Ключевые моменты
Транзакционная целостность: запись данных и события в БД — в рамках одной транзакции (ACID).
Фоновый процесс может быть развернут в нескольких инстансах для масштабирования.
События должны иметь поле, по которому можно определить что событие одно и то же (такое поле называется ключ идемпотентности). Они нужны чтобы повторная доставка не привела к дублированию.
Потребителям нужно использовать дедубликацию на основе ключа идемпотентности.
🧠 Вопросы, которые могут задать
Почему не отправлять событие напрямую в брокер в той же транзакции?
Т.к. брокер и БД не поддерживают распределённые транзакции, риск рассинхронизации если отправка будет успешна а транзакция не закроется.
Как работает идемпотентность в TO?
Ключи сообщений (например, message_id), которые позволяют потребителю игнорировать дубликаты.
Какие таблицы участвуют?
Основная таблица (например, orders) + таблица outbox.
Например
CREATE TABLE outbox (
id UUID PRIMARY KEY,
payload JSONB NOT NULL,
sent BOOLEAN NOT NULL DEFAULT FALSE,
);
💡 Основные плюсы TO:
✅ Минимизирует риск потери данных.
✅ Поддержка высокой доступности и отказоустойчивости.
✅ Простая реализация в рамках одного микросервиса.
🔥3👍2
Вчера вышло новое видео про паттерн Transactional Outbox
Если готовишься к собесам на middle/senior бэкенд или просто нравится архитектура - must have к просмотру
Смотреть на YouTube📹
Смотреть на Boosty (Без VPN)💳
Если готовишься к собесам на middle/senior бэкенд или просто нравится архитектура - must have к просмотру
Смотреть на YouTube
Смотреть на Boosty (Без VPN)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4
📘 Рекомендации от Microsoft по проектированию API
Полную статью можно почитать тут - Best practices for API design
🔗 Следуйте REST-принципам
- Стройте API вокруг ресурсов (
- Используйте правильные HTTP-методы:
- Методы
🧠 Делайте API stateless
- Каждый запрос должен содержать всё необходимое — контекст, аутентификацию и параметры.
- Сервер не должен хранить состояние между вызовами.
📦 Минимизируйте количество вызовов
- Избегайте "болтливого" API. Комбинируйте связанные данные в одном ответе, чтобы снизить нагрузку на сеть и улучшить производительность.
- Например вместе с данными о посте можно сразу возвращать количество комментариев, лайков и просмотров.
📄 Используйте OpenAPI
- OpenAPI-спеки упрощают генерацию документации, SDK, моков и тестов. Ускоряет разработку и улучшает поддержку.
🛡 Разделяйте публичные и внутренние API
- Внешние API — http и RESTful.
- Внутренние — можно оптимизировать под производительность, например используя gRPC.
🚪 Используйте API Gateway
- Azure API Management или аналог.
- Gateway может выполнять разные задачи - кеширование, маршрутизация, защита от атак, ограничение трафика, аналитика.
♻️ Версионируйте и управляйте изменениями
- Обновляйте API без поломки старых клиентов. Используйте CI/CD для автоматического выката и управления версиями.
- Например
Полную статью можно почитать тут - Best practices for API design
🔗 Следуйте REST-принципам
- Стройте API вокруг ресурсов (
/users/123)- Используйте правильные HTTP-методы:
GET, POST, PUT, DELETE. Это улучшает читаемость и предсказуемость.- Методы
GET, PUT, DELETE должны быть идемпотентными: повторный запрос не должен менять результат.🧠 Делайте API stateless
- Каждый запрос должен содержать всё необходимое — контекст, аутентификацию и параметры.
- Сервер не должен хранить состояние между вызовами.
📦 Минимизируйте количество вызовов
- Избегайте "болтливого" API. Комбинируйте связанные данные в одном ответе, чтобы снизить нагрузку на сеть и улучшить производительность.
- Например вместе с данными о посте можно сразу возвращать количество комментариев, лайков и просмотров.
📄 Используйте OpenAPI
- OpenAPI-спеки упрощают генерацию документации, SDK, моков и тестов. Ускоряет разработку и улучшает поддержку.
🛡 Разделяйте публичные и внутренние API
- Внешние API — http и RESTful.
- Внутренние — можно оптимизировать под производительность, например используя gRPC.
🚪 Используйте API Gateway
- Azure API Management или аналог.
- Gateway может выполнять разные задачи - кеширование, маршрутизация, защита от атак, ограничение трафика, аналитика.
♻️ Версионируйте и управляйте изменениями
- Обновляйте API без поломки старых клиентов. Используйте CI/CD для автоматического выката и управления версиями.
- Например
/api/v1/users/123/api/v2/users/123❤1🤔1
Есть Leetcode - тренажер для алгоритмических задач, есть sql-ex - тренажер для задач по SQL.
Но на многих собеседованиях предлагают сделать код-ревью какого-то production-like кода, где нужно учитывать особенности работы с бд, сетевых запросов, работу в многопоточной среде и читаемость кода.
Для таких задач сложно придумать тренажер, но с появлением нейронок можно сделать почти все, главное написать хороший промпт.
Мой вариант ниже, если есть что добавить - пиши в комменты✉️
📎 Промпт для тренировки код-ревью с ChatGPT
Но на многих собеседованиях предлагают сделать код-ревью какого-то production-like кода, где нужно учитывать особенности работы с бд, сетевых запросов, работу в многопоточной среде и читаемость кода.
Для таких задач сложно придумать тренажер, но с появлением нейронок можно сделать почти все, главное написать хороший промпт.
Мой вариант ниже, если есть что добавить - пиши в комменты
📎 Промпт для тренировки код-ревью с ChatGPT
Представь, что я хочу тренироваться в навыке код-ревью на языке {ЯЗЫК_ПРОГРАММИРОВАНИЯ}.
Сгенерируй для меня исходный код (например, одного файла или небольшого модуля), в котором специально внедрены ошибки. Ошибки должны быть разного уровня сложности: от базовых (логических, синтаксических, архитектурных) до более сложных, которые может заметить только опытный разработчик.
Пусть некоторые ошибки будут связаны с взаимодействием с базой или сетевыми вызовами, работой в многопоточной среде.
Формат:
Сначала просто покажи мне код, не объясняя и не перечисляя ошибки.
Жди, пока я самостоятельно отправлю тебе список найденных мною ошибок (в одном или нескольких сообщениях).
Когда я напишу, что "закончил" или "больше ошибок не вижу", сравни мой список с настоящим списком внедрённых ошибок:
Подтверди, какие ошибки я правильно заметил.
Укажи, какие ошибки я пропустил и почему они важны.
При необходимости — дополни контекстом или best practices.
Не подсказывай, пока я не попрошу или не завершу.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍1
Как готовиться к собесам?
📞 Скрининг (HR-интервью)
Нужно быть готовым к стандартным вопросам:
— Расскажи о себе и самом интересном опыте
— Почему ищешь работу, что не устраивает в текущей компании
— Чего ждешь от нового места, на что будешь обращать внимание при выборе оффера
— Зарплатные ожидания
🧠 Теоретическая часть
- Гуглим "Топ-100 вопросов по Go/Java/Python/Postgres/Kafka...
- Сначала пробуем ответить но вопрос вслух, только потом читаем ответ
- Можно попросить кого-то провести тебе мок собеседование, чтобы привыкнуть к формату
- Также мок-собеседование может проводить нейронка
👨💻 Лайвкодинг
- Решаем задачи на Leetcode, не пользуясь IDE
- Также можно пользоваться Geekforces
- Хороший показатель готовности - решаешь 2 medium задачи за час (на собесах обычно просят 1 easy и 1 medium, но ты при этом еще волнуешься, так что лучше готовиться с запасом)
- Вот к чему рекомендует готовиться Яндекс на своих собеседованиях:
Лайвкодинг-SQL
- Выучить операторы
- Тренироваться можно на SQL-ex, там стоит прорешать хотя бы первые 10-15 задач, можно больше.
Лайвкодинг-ревью
- Промпт для тренировки код-ревью с нейронкой - тут
🧱 System Design
- Записи system-design интервью на ютуб, пару примеров
- https://youtu.be/ioEHnd_fpFA
- https://youtu.be/Wh5Ya6UFG1k
- https://youtu.be/9_8ShTF6aQA
- Можно самому пытаться строить систему по требованиям из видео, а потом сравнивать с тем что получилось у участника.
- Книга "System Design. Подготовка к сложному интервью | Алекс Cюй"
- Если много времени и желания - книга "Высоконагруженные приложения | Мартин Клеппман"
🧠 Поведенческое и финал
- Вспомнить(придумать ) конфликтные и/или стрессовые ситуации на работе
- Продумать рассказы о них, чтобы показать свои сильные стороны: как решал конфликты, как действовал в стрессовых ситуациях чтобы максимально быстро починить прод/максимально рано предупредить стейкхолдера о срыве сроков.
📞 Скрининг (HR-интервью)
Нужно быть готовым к стандартным вопросам:
— Расскажи о себе и самом интересном опыте
— Почему ищешь работу, что не устраивает в текущей компании
— Чего ждешь от нового места, на что будешь обращать внимание при выборе оффера
— Зарплатные ожидания
🧠 Теоретическая часть
- Гуглим "Топ-100 вопросов по Go/Java/Python/Postgres/Kafka...
- Сначала пробуем ответить но вопрос вслух, только потом читаем ответ
- Можно попросить кого-то провести тебе мок собеседование, чтобы привыкнуть к формату
- Также мок-собеседование может проводить нейронка
👨💻 Лайвкодинг
- Решаем задачи на Leetcode, не пользуясь IDE
- Также можно пользоваться Geekforces
- Хороший показатель готовности - решаешь 2 medium задачи за час (на собесах обычно просят 1 easy и 1 medium, но ты при этом еще волнуешься, так что лучше готовиться с запасом)
- Вот к чему рекомендует готовиться Яндекс на своих собеседованиях:
Задачи уровня easy и medium с тегами: Array, String, Tree, Binary Search, Hash table, Depth-first Search, Breadth-first Search, Two Pointers, Stack, Backtracking; а также задачи с разными уровнями acceptance.
Лайвкодинг-SQL
- Выучить операторы
SELECT
JOIN --(INNER, LEFT, RIGHT)
WHERE
GROUP BY
HAVING
-- и аггрегатные функции MAX, COUNT, AVG etc
- Тренироваться можно на SQL-ex, там стоит прорешать хотя бы первые 10-15 задач, можно больше.
Лайвкодинг-ревью
- Промпт для тренировки код-ревью с нейронкой - тут
🧱 System Design
- Записи system-design интервью на ютуб, пару примеров
- https://youtu.be/ioEHnd_fpFA
- https://youtu.be/Wh5Ya6UFG1k
- https://youtu.be/9_8ShTF6aQA
- Можно самому пытаться строить систему по требованиям из видео, а потом сравнивать с тем что получилось у участника.
- Книга "System Design. Подготовка к сложному интервью | Алекс Cюй"
- Если много времени и желания - книга "Высоконагруженные приложения | Мартин Клеппман"
🧠 Поведенческое и финал
- Вспомнить(
- Продумать рассказы о них, чтобы показать свои сильные стороны: как решал конфликты, как действовал в стрессовых ситуациях чтобы максимально быстро починить прод/максимально рано предупредить стейкхолдера о срыве сроков.
🔥3👍2
Вчера вышло новое видео, где рассказываю базу про IT собесы
Смотреть на YouTube📹
Смотреть на Boosty (Без VPN)💳
Смотреть на YouTube
Смотреть на Boosty (Без VPN)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1