Gh0st dev | Всякое про IT – Telegram
Gh0st dev | Всякое про IT
97 subscribers
53 photos
22 links
Тут полезные материалы, советы и мемы про айтишечку и всякое около нее
___
by @dsvtlg
Download Telegram
Алгоритмические собеседования VS Читай-город

Многие крупные компании рекомендуют кандидатам книгу "Грокаем алгоритмы".

Именно эта книга заняла первое место в топе самых воруемых книг за год, которую опубликовал читай город.

Теперь чтобы получить оффер в Яндекс, надо пройти не только собеседование, но еще и мимо охранника в книжном.

За год в «Читай-городе» украли 300 тыс. книг
В 2024 году в среднем по итогам инвентаризации в сети «Читай-город» не досчитались 300 тыс. книг. По сравнению с 2023 годом количество пропаж не изменилось, уточнили в компании. Лидером пропаж стала книга для айтишников. При этом уточняется, что школьные издания пропадали в три раза реже, чем годом ранее.
🌚2🎃11
Пишу -8000 строк кода в день, кстати
🔥5
🛠 Как можно нагрузить приложение? OLAP vs OLTP

Когда в вакансии пишут «опыт работы с высоконагруженными приложениями», что это значит? Это про миллионы запросов в секунду, как у соцсетей, или про сложные аналитические вычисления, как у систем отчетности?

На самом деле, здесь речь может идти о двух совершенно разных типах нагрузки: OLTP и OLAP.
Разберемся, чем они отличаются.


ℹ️ OLTP (Online Transaction Processing)
Это транзакционная нагрузка. То, о чем думают большинство людей, когда слышат словосочетание "высоконагруженное приложение".

Такая нагрузка подразумевает очень много не сложных операций.
На примере соц. сетей это могут быть - получение ленты подписок, получение всех диалогов пользователя, получение списка друзей, списка комментариев к записи, и так далее.

Выполнить одну такую операцию очень просто, но поддерживать доступность сервиса, когда таких запросов десятки тысяч в секунду - уже сложная задача.

Здесь пригодится знание кэшей, шардирования БД и скейлинга stateless сервисов.

🚛 OLAP (Online Analytical Processing)
Аналитическая нагрузка - полная противоположность. Самих операций очень мало, вплоть до 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 коммитов

Это и есть тот самый призрачный разработчик? 👀
Это призрачный разработчик?
Anonymous Poll
52%
Да 👻
19%
Нет ✖️
30%
Что такое запушил? 🧐
📦 Transactional 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) 💳
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4
📘 Рекомендации от Microsoft по проектированию API
Полную статью можно почитать тут - 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


Представь, что я хочу тренироваться в навыке код-ревью на языке {ЯЗЫК_ПРОГРАММИРОВАНИЯ}.
Сгенерируй для меня исходный код (например, одного файла или небольшого модуля), в котором специально внедрены ошибки. Ошибки должны быть разного уровня сложности: от базовых (логических, синтаксических, архитектурных) до более сложных, которые может заметить только опытный разработчик.
Пусть некоторые ошибки будут связаны с взаимодействием с базой или сетевыми вызовами, работой в многопоточной среде.

Формат:

Сначала просто покажи мне код, не объясняя и не перечисляя ошибки.

Жди, пока я самостоятельно отправлю тебе список найденных мною ошибок (в одном или нескольких сообщениях).

Когда я напишу, что "закончил" или "больше ошибок не вижу", сравни мой список с настоящим списком внедрённых ошибок:

Подтверди, какие ошибки я правильно заметил.

Укажи, какие ошибки я пропустил и почему они важны.

При необходимости — дополни контекстом или best practices.

Не подсказывай, пока я не попрошу или не завершу.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍1
Please open Telegram to view this post
VIEW IN TELEGRAM
Как готовиться к собесам?

📞 Скрининг (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) 💳
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1