15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Если честно, я всё чаще замечаю, что бэкенд-сообщество – невероятно разное. Здесь есть и те, кто только начинает разбираться в сервисах и базах, и те, кто уже пишет такие системы, которые держат на себе половину интернета. Но есть одна общая черта: хороших бэкендеров формирует не только практика, но и среда, в которой они находятся.
Мы растём быстрее, когда видим, как мыслят другие разработчики: какие решения принимают, какие компромиссы выбирают, как подходят к сложным задачам. И иногда одна чужая история или разбор может дать гораздо больше, чем длинные учебники или курсы.
Поэтому хочу поделиться небольшой папкой каналов, где собраны разработчики, которые по-разному мыслят, по-разному пишут и по-разному растут. Среди них есть те, кто ежедневно ковыряет продакшен, те, кто давно ушёл в архитектуру, и те, кто пробует силы в смежных направлениях.
Если вы работаете с бэкендом, то скорее всего, найдёте там что-то ценное для себя: идеи, подходы, вдохновение или даже ответы на вопросы, которые давно крутились в голове.
Хорошая среда делает нас сильнее 😎
SQL + SELECT = выбор данных
SQL + JOIN = объединение данных
SQL + WHERE = фильтрация
SQL + GROUP BY = агрегация
SQL + ORDER BY = сортировка
SQL + UNION = объединение запросов
SQL + INSERT = добавление записей
SQL + UPDATE = изменение данных
SQL + DELETE = удаление записей
SQL + CREATE TABLE = проектирование структуры
SQL + ALTER TABLE = изменение схемы
SQL + DROP TABLE = удаление таблицы
SQL + INDEX = ускорение запросов
SQL + VIEW = виртуальные таблицы
SQL + подзапросы = вложенные запросы
SQL + хранимые процедуры = автоматизация задач
SQL + триггеры = автоматические реакции на события
SQL + CTE = рекурсивные запросы
SQL + оконные функции = продвинутая аналитика
SQL + транзакции = целостность данных
SQL + ACID = надежные операции
SQL + хранилища данных = работа с большими объёмами
SQL + ETL = преобразование данных
SQL + партиционирование = работа с большими таблицами
SQL + репликация = высокая доступность
SQL + шардинг = масштабирование базы
SQL + JSON = полуструктурированные данные
SQL + XML = структурированные данные
SQL + безопасность данных = защита информации
SQL + оптимизация запросов = повышение производительности
SQL + управление данными = контроль качества данных
Вопрос:
try {
call_order_service();
call_inventory_service(); // уменьшаем остатки
} catch (Exception e) {
// лол, и что теперь? Заказ уже создан.
}
Разработчик ускорил загрузку сайта при работе в браузере ladybird почти в три раза. Время рендера сократилось примерно с одной секунды до четырёхсот миллисекунд.
Оптимизация получилась за счёт двух изменений:
- в HTTP-кеш добавили поддержку heuristic freshness lifetime в соответствии с RFC 9110 и 9111
- рендер теперь стартует только после получения всех CSS-импортов, так что эффект FOUC больше не появляется
👉 @BackendPortal
Заголовки безопасности сломали мобильное приложение
Никто не протестировал мобилку — и вот что получилось.
Что изменили
- Добавили security headers в API:
- Content-Security-Policy
- X-Frame-Options
- X-Content-Type-Options
- Strict-Transport-Security
- Почувствовали себя уверенно насчет безопасности
Что пошло не так
- Деплой в пятницу вечером
- Веб-приложение работало нормально
- Мобильное приложение полностью упало
- Данные не грузились
- Итог: инцидент на выходных
Расследование
- API показывал успешные запросы
- Логи мобильного клиента показывали ошибки
- Ответы: 200 OK
- Но мобильное приложение получало пустые данные
- Сетевой слой просто отбрасывал ответы
Виновник
- Content-Security-Policy
- Приложение использовало встроенный WebView
- CSP блокировал WebView при обработке ответов
- Браузерные правила безопасности применялись в мобильном контексте
- Хедер предназначен для браузеров, а не для API
Почему это пропустили
- Тестировали только веб
- Мобильная команда не была подключена к изменению
- Не было mobile testing в staging
- Предположили, что заголовки безопасны "по умолчанию"
- Не было feature-флагов для отката
Экстренный фикс
- Временно удалили CSP
- Горячий фикс в production
- Мобилка снова заработала
- Итого: 8 часов даунтайма
Правильное решение
- Разные заголовки для API и веба
- Логика на основе User-Agent
- Отдельная CSP-политика для мобильных клиентов
- Полное кроссплатформенное тестирование
- Feature-флаги для security-изменений
Урон
- Даунтайм: 2 часа
- Затронутых пользователей: 125 000
- Рейтинг в сторе: 4.7
Security headers не универсальны.
Тестируйте на всех платформах.
Web security и API security — разные вещи.
👉 @BackendPortal
⚡️ На Stepik вышел курс по Linux
Ребята сделали крутейший курс по Linux, где понятным языком, шаг за шагом, на реальных примерах и с наглядными схемами обучают работе с этой ОС
Внутри 20+ модулей: от установки Linux и работы с файлами до сетей, прав, дисков, процессов, автоматизации на Bash и многого другого. Всё сразу закрепляется на практике (200+ заданий с автопроверкой).
После прохождения вы получите сертификат, который можно добавить в резюме.
Есть бесплатные демо-уроки для ознакомления. В ближайшие 48ч курс доступен со скидкой 25% по промокоду «LINUXTG25»: открыть курс на Stepik
Насколько быстро каждый язык перемножает две матрицы 1000×1000?
Примерные бенчмарки:
C++: ~220 мс
Rust: ~250 мс
Go: ~500 мс
Java: ~700 мс
Python (NumPy): ~80 мс*
JS: ~3 с
*NumPy под капотом дергает оптимизированный C/BLAS – на чистом Python это заняло бы несколько секунд.
Перемножение матриц – вычислительно тяжелая задача, в которой основную роль играют операции с плавающей запятой и работа с кэшем.
Большинство реализаций используют классический тройной цикл O(n³), который отлично подходит для проверки сырой производительности CPU и того, насколько хорошо компилятор оптимизирует вложенные циклы.
👉 @BackendPortal
Стратегии версионирования API:
1. Версионирование через URI— добавление номера версии в URL для ясности и простоты.
Пример: /api/v1/products.
2. Версионирование через путь — версия встраивается непосредственно в путь API для наглядности.
Пример: /api/v2/products.
3. Query Parameter Versioning — версия указывается как параметр запроса, сохраняя чистоту структуры URL.
Пример: /api/products?version=1.
4. Subdomain Versioning — для каждой версии используются отдельные поддомены, полностью разделяя их.
Пример: v2.api.example.com/products.
5. Header Versioning — версия передаётся в заголовках запроса, URL остаётся неизменным.
Пример: GET /products Header: Accept: application/vnd.example.v1+json.
6. Timestamp Versioning — версии основаны на временных метках, что обеспечивает гибкость при релизах.
Пример: /api/products?version=2023-10-01.
7. Content Negotiation — использует заголовок Accept для запроса разных версий и форматов.
Пример: GET /products Header: Accept: application/json; version=1.
8. Semantic Versioning — следует семантическому версионированию (например, v1.0.0) для обозначения основных, второстепенных и патчевых изменений.
Пример: /api/products/v1.0.0
👉 @BackendPortal
Pytup — митап для Python-разработчиков и ML-инженеров
27 ноября в 17.00 (по Екб) | Екатеринбург | офлайн и онлайн
Встречаемся сообществом экспертов в Python и машинном обучении, чтобы обсудить тренды, новые подходы и технологии, которые двигают индустрию вперед.
В центре встречи — выступления экспертов из Яндекса, VK и других компаний. Арсений Саблин, разработчик системы контроля качества умных устройств на производстве (Яндекс Алиса), объяснит, как используется Python при тестировании станций с Алисой, а Никита Улько, техлид из VK Tech, разберет чистую архитектуру с практической точки зрения.
Программа еще дополняется — полный список спикеров и активностей можно посмотреть на сайте.
После докладной части гости встречи в Екатеринбурге смогут принять участие в дискуссионных столах, гонках на игрушечных роверах и соревнованиях по игре в змейку. Встречаемся в креативном кластере «Домна» или онлайн-трансляции.
👉Регистрация на митап
Недавно я говорил о том, чтобы просто использовать Postgres вместо Kafka. Вот Apache-лицензированный stateless-прокси для Kafka с подключаемым бэкендом на Postgres (или SQLite, или S3).
Что мешает встроить это прямо в Postgres как расширение?
Такое расширение могло бы предоставлять SQL-функции для pub/sub и поднимать настоящий Kafka TCP-сервер (через background worker). Тогда всё оставалось бы совместимым с Kafka-протоколом прямо внутри базы. И при этом обе части использовали бы одни и те же таблицы.
👉 @BackendPortal
Веб работает поверх HTTP.
А HTTP без состояния: сервер не помнит, что было между запросами.
Если ты переходишь со страницы на страницу, сервер не знает, что это всё ещё ты. Нужно как-то сказать ему: «эй, я тот же самый».
Для этого и существуют Cookies.
Cookie это кусочек данных, который браузер сохраняет и отправляет серверу при каждом запросе.
Классический пример: хранение токена сессии (например, JWT) для авторизации.
Но не все данные стоит отправлять на сервер.
Есть вещи, важные только для интерфейса: тема (светлая/тёмная), язык, прошёл ли пользователь onboarding и т. п.
Для этого есть Web Storage, и у него два варианта:
localStorage — данные сохраняются даже после закрытия браузера.
sessionStorage — очищается, как только закрываешь вкладку.
Итог:
Cookies для данных, которые должны идти на сервер.
Storage для того, что должно оставаться только в браузере.
👉 @BackendPortal
Podman — «альтернативный» контейнерный рантайм, который на первый взгляд напоминает Docker своими командами «podman pull», «podman run», «podman exec» и т. д. Однако под капотом он использует несколько иную бездемонную архитектуру
Начните работу с Podman на https://labs.iximiuz.com/challenges/start-container-with-podman
👉 @BackendPortal
Когда количество записей в базе переваливает за миллиард, запросы, которые раньше выполнялись за миллисекунды, начинают тянуться по несколько секунд, а пакетные задачи по несколько часов. Такие просадки в производительности становятся катастрофой для любой системы. А здесь речь идёт о платежах, заказах и бухгалтерских данных финансовой платформы, где бизнес не допускает даже секунды простоя.
Эта статья основана на реальном кейсе и показывает пошаговое решение проблемы. Суть подхода в том, чтобы разбить риски на управляемые этапы: сначала перенести «холодные» неизменяемые данные, обрабатывая их параллельно по шардам по первичному ключу, временно отключив индексы ради ускорения. Затем включить механизм двойной записи: каждая новая транзакция одновременно пишется и в старую, и в новую базу. Неудачные записи отправляются в Kafka для повторных попыток, чтобы гарантировать итоговую согласованность данных.
Самое интересное решение - это фаза «теневого чтения». Пользовательские запросы по-прежнему читаются из старой базы, но в фоне тот же запрос выполняется и на новой, а результаты сравниваются. Этот этап длится несколько недель, и именно за это время команда выявляет проблемы, которые невозможно поймать в тестовой среде: различия в обработке часовых поясов, поведении по умолчанию при NULL-значениях, правилах сортировки символов и т. п. Эти нюансы всплывают только под реальной нагрузкой.
Финальное переключение проводится ранним утром, когда трафик минимален. К этому моменту кэш и индексы новой базы заранее «разогреты» синтетическими запросами. Затем постепенно переводится поток чтений, управляемый через feature-флаги. Команда отслеживает задержки, процент ошибок и бизнес-метрики на дашбордах в Grafana, подтверждая успех миграции только спустя 24 часа стабильной работы.
Такой подход можно смело брать на вооружение при миграциях баз данных, например, в рамках перехода на инфраструктуру Xinchuang. Здесь выделяются три ключевых принципа:
Постепенный контроль рисков: каждый шаг можно проверить и при необходимости откатить.
Валидация на реальном трафике: «теневое чтение» выявляет несовместимости лучше любых тестов.
Наблюдаемость прежде всего: от внутренних WAL-логов и hit-рейтов кэша до бизнес-метрик по заказам и выручке, полный мониторинг позволяет вовремя заметить аномалии.
👉 @BackendPortal
То, что доктор прописал!
9 самых необходимых IT-каналов, которые должен читать каждый айтишник:
Доктор Mobile - лечим ваш смартфон, минимум слов, максимум пользы.
Доктор Python — коды, хаки и фичи.
Доктор Techlogy — свежие технологии и их применение.
Доктор Cyber — информационная безопасность без скуки.
Доктор GitHub — лучшие репозитории от врача.
Доктор IT — всё о цифровом мире и его инсайтах.
Доктор GameDev — рецепты создания игр и гайды.
Доктор GPT — лучшие промпты и сервисы ИИ.
Доктор Memes — смех лечит лучше любых апдейтов.
Доктор C++ — фичи, советы и код без боли.
Подпишись, чтобы стать профессором, а не пациентом.
🔥Горячие IT вакансии которых нет на HH.
Вакансии, только с прямыми контактами в Telegram! Ноль автоотказов — живой диалог и быстрые объективные решения.
🤖 ML & DS 👩💻 DevOps
👩💻 Java 👣 Go
👩💻 Mobile 👩💻 C#
👩💻 Node.js 👩💻 Python
🔎 QA 👨✈️ CyberSec
👩💻 UX/UI 👩💻 Frontend
🖼️ PHP 📋 Analyst
💼 1C 🖥 SQL
👩💻 IT HR
Подпишись чтобы не упустить свой шанс получить лучший оффер!
25 золотых правил системного дизайна
1. Система с упором на чтение
> Используй кэш (Redis/Memcached) для частых запросов вроде профилей пользователей
2. Низкая задержка
> Используй кэш и CDN (Cloudflare), чтобы раздавать статику ближе к пользователю
3. Система с упором на запись
> Используй Message Queue (Kafka) для буферизации большого объема записей (логи, аналитика)
4. ACID-требования
> Используй SQL (PostgreSQL) для строгих транзакций вроде банковских операций
5. Неструктурированные данные
> Используй NoSQL (MongoDB) для гибких схем, например каталогов товаров
6. Сложные медиа-ресурсы
> Используй Blob Storage (AWS S3) для видео, изображений и больших файлов
7. Сложные предварительные расчёты
> Используй Message Queue + Cache для асинхронной генерации контента (например ленты новостей)
8. Поиск при больших объемах данных
> Используй Elasticsearch для полнотекстового поиска и автокомплита
9. Масштабирование SQL
> Используй шардирование, чтобы разделить большие таблицы на несколько инстансов
10. Высокая доступность
> Используй Load Balancer (NGINX) чтобы распределять трафик и избегать перегрузки
11. Глобальная доставка данных
> Используй CDN для стабильного стриминга и раздачи контента по всему миру
12. Графовые данные
> Используй Graph DB (Neo4j) для соцсетей, рекомендаций и связей между сущностями
13. Масштабирование компонентов
> Используй горизонтальное масштабирование, а не просто апгрейд железа
14. Быстрые запросы к базе
> Используй индексы на ключевых колонках вроде email или user_id
15. Пакетные задачи
> Используй Batch Processing для отчётов, расчётов или периодических задач
16. Защита от злоупотреблений
> Используй Rate Limiter, чтобы предотвращать DDoS и спам запросов к API
17. Доступ к микросервисам
> Используй API Gateway для авторизации, маршрутизации и SSL-терминации
18. Единая точка отказа
> Добавляй Redundancy (Active-Passive), чтобы сервис продолжал работать при сбоях
19. Отказоустойчивость данных
> Используй репликацию (Master-Slave), чтобы данные не терялись при падении узлов
20. Реальное время
> Используй WebSockets для чатов, лайв-обновлений, лайв-результатов
21. Обнаружение сбоев
> Используй Heartbeat-пинг, чтобы проверять статус сервисов каждые несколько секунд
22. Целостность данных
> Используй Checksums (MD5/SHA) чтобы проверить, что загруженные файлы не повреждены
23. Децентрализованное состояние
> Используй Gossip Protocol, чтобы ноды обменивались статусами без центрального сервера
24. Эффективное кеширование
> Используй Consistent Hashing, чтобы добавлять или убирать кэш-ноды без полного пересчёта ключей
25. Работа с геоданными
> Используй Quadtree или Geohash для быстрых запросов вроде поиска ближайших водителей
Случайные UUID заметно просаживают производительность базы
Ты перешел с integer ID (1, 2, 3…) на UUID (a1b2-3c4d-…) ради безопасности или распределенной генерации.
И вдруг вставки стали медленнее. Иногда намного.
Причина простая - фрагментация индекса.
Большинство индексов в базах данных это B-деревья (сбалансированные сортированные структуры). Физическое расположение данных в индексе реально важно.
Последовательные ID
Когда ты вставляешь последовательные целые числа (1, 2, 3), новые записи всегда попадают в правую страницу листа индекса.
Все максимально предсказуемо:
- записи идут последовательно
- кэш работает эффективно
- страницы заполняются полностью
Это почти максимальная скорость, на которую способна твоя база.
Случайные UUIDv4
UUIDv4 генерируются равномерно случайно. Вставка может попасть в любое место структуры B-дерева.
Из-за хаотичного распределения:
База должна постоянно подгружать случайные страницы с диска в память. Это random I/O.
Page splitting: когда страница заполнена, ее приходится делить на две, оставляя обе наполовину пустыми.
Эффект "швейцарского сыра": индекс раздувается, полон дыр и плохо использует RAM и место на диске.
Когда размер индекса превышает доступную оперативку, пропускная способность записи может просесть на 20–90%.
UUIDv7
Хватит использовать UUIDv4 в качестве primary key. Переходи на UUIDv7 (стандарт RFC 9562).
UUIDv7 содержит timestamp в начале, так что значения становятся сортируемыми.
Что это дает:
Генерация без центрального счетчика
Вставки идут монотонно, почти как обычные последовательные числа
Фрагментация индекса исчезает
Защита от угадывания ID (хотя по ID можно понять время вставки)
Получается удобство UUID, но без потерь по производительности.
Короче, UUIDv7 норм. UUIDv4 не особо, если используешь как primary key.
👉 @BackendPortal
Большинство споров про Docker рано или поздно приходят к одному вопросу: slim или alpine, какой базовый образ выбрать?
Alpine очень маленький, выглядит привлекательно, если хочется сильно урезать размер образа. Но он использует musl вместо glibc, поэтому некоторые приложения ведут себя иначе, часть библиотек работает криво, а отладка может превратиться
Хороший вариант, если у тебя простое приложение или статический бинарник без кучи зависимостей на уровне ОС.
Slim-образы, вроде debian:slim или node:22-slim, больше Alpine, но всё ещё намного легче полноценных системных образов.
Они используют glibc, так что большинство тулов и библиотек работает нормально.
Обычно это означает меньше сюрпризов в проде, проще дебаг и лучше совместимость с документацией и примерами в сети.
Для большинства веб-приложений, API и инструментов slim = более безопасный выбор по умолчанию. Размер образа всё ещё небольшой, скачивается быстро, безопасность ок, и при этом не приходится ловить странные баги, связанные с musl.
Alpine имеет смысл, если ты:
поставляешь один статический бинарник
хорошо понимаешь свои зависимости
готов разруливать совместимость, если что-то поедет боком
🚀 Сначала запусти, а потом улучшай
Эту мантру знает каждый успешный фаундер. Главный риск в IT — застрять в перфекционизме и так и не выйти на рынок. Ценится скорость!
Яркий пример — челлендж «12 запусков за 12 месяцев» в комьюнити «Короче, Капитан». Вот как это работает у них:
⚡️Фокус. Берёте одну проблему с проверенным спросом. Никаких догадок.
⚡️Скорость и бюджет. Ровно месяц на разработку и запуск в США/ЕС. Средний бюджет на продвижение — всего $150.
⚡️Анализ. В конце месяца — честный разбор: что сработало, а что нет.
Вы в реальном времени видите запуск, продвижение и доход по каждому проекту. Идеальный способ прокачать насмотренность и перенять работающие подходы — даже если вы инженер, а не фаундер.
В будущем гарантированно набьете меньше шишек 💡
👉 Подписаться: @its_capitan
Когда нужно работать с данными в реальном времени, обычный HTTP не лучший вариант.
В HTTP клиент отправляет запрос, сервер отвечает и соединение закрывается. И важный момент: коммуникацию всегда инициирует клиент.
Для статей или обычных страниц это норм. Но если ты пишешь чат, такой подход развалится.
Придётся каждые пару секунд спрашивать сервер: "Есть новые сообщения?" Это грузит CPU, создаёт кучу лишних запросов и добавляет задержку. Такой подход называется polling.
Чтобы это решить, появился WebSocket.
Главная идея:
"Соединение остаётся открытым, и обе стороны могут общаться когда захотят."
Уменьшил размер Docker-образа с 2.1GB до 180MB. Деплой стал в 8 раз быстрее.
Как выглядел исходный Dockerfile:
Брался ubuntu:latest
Все ставилось через apt
В образ попадали дев зависимости
Копировалась вся директория проекта
Остались билд-артефакты
Не было оптимизации слоев
Pull занимал 6–8 минут
Хранилище в registry стоило дорого
Деплой тянулся слишком долго
Скан безопасности показал 47 уязвимостей
Большинство — из ненужных пакетов
Убрали дев зависимости
Использовали multi-stage build
В прод версию попали только нужные пакеты
Сначала копировали requirements
Устанавливали зависимости
Потом копировали исходники
Использовали кэш слоев Docker
🚨 На Stepik вышел долгожданный курc: "Грокаем паттерны SQL-собеседований"
Курс помогает не зубрить SQL, а понимать его. Ты начинаешь видеть в задачах знакомые структуры, связывать их с реальными бизнес-ситуациями и применять решения, которые ждут на интервью в серьёзных компаниях. 😎
Преподаватели берут то, с чем сами сталкиваются в повседневной работе Data Scientist, AI/ML Engineer, Data Engineer и Data Analyst, и превращают это в понятные практические упражнения.
Задачи в духе LeetCode, разбор живых кейсов, приёмы оптимизации. Всё, что позволяет уверенно чувствовать себя на собеседовании и дальше уже в команде.
Для подписчиков канала, выдаётся скидка в 25%
Разработчик объявил о завершении работы над Conflux — модульным акторным движком для совместной работы в реальном времени, написанным на Rust.
В проекте используются CRDT через Yrs, комнатный WebSocket и акторная модель для конкурентности. В свежую версию добавлены JWT, аутентификация, трекинг сессий, синхронизация awareness и дашборд-эндпоинт для просмотра активных комнат.
Каждая комната изолирована и живёт по своему циклу: поднимается, работает и очищается автоматически.
Исходники уже доступны на GitHub, а позже автор опубликует блог с подробностями архитектуры и объяснением, как под капотом устроена синхронизация CRDT.
👉 @BackendPortal
Ты логинишься, начинаешь сессию… но для сервера каждый запрос выглядит как новый.
Откуда он знает, что это снова ты?
Для этого и придумали JWT
Это токен, который сервер генерирует, чтобы идентифицировать пользователя. В нем лежат данные вроде id или email, а сам токен подписан секретным ключом, чтобы его нельзя было подделать.
Он не хранит пароли или что-то сверхчувствительное - только минимум, по которому сервер сможет узнать тебя позже.
Схема работает так:
Ты отправляешь логин и пароль на сервер.
Сервер проверяет их, создает JWT и подписывает его секретным ключом.
Токен отправляется в браузер, который сохраняет его, например, в куке.
С каждым новым запросом браузер снова отправляет этот токен.
Сервер проверяет подпись и, если все ок, понимает, что запрос идет от того же пользователя.
Так и работает аутентификация в статeless-среде вроде HTTP.
Иногда используют еще и refresh token, чтобы обновлять JWT, когда тот истечет.
Есть и другие подходы: сервер может хранить сессии у себя и искать нужную запись по каждому запросу.
👉 @BackendPortal
Какие задачи решает метапрограммирование? В чём польза scalamock? А что надёжнее: типы или тесты?
Эти и другие темы разберём на F[Scala] 2025 — самой масштабной конференции по Scala и ФП в России.
🔵В этом году команда Яндекс Вертикалей подготовила особенно насыщенную программу: 2 зала с докладами, воркшоп, круглый стол и другие активности.
Вместе со спикерами из Яндекса, Т-Банка, Сбера и других компаний обсудим ZIO, метапрограммирование, Big Data и распределённые системы на Scala, Clojure и Erlang.
➡️Подробности и регистрация
Запросы к базе тормозили. Все винтили базу.
RDS ок: 12% CPU, время запросов меньше 10 мс.
Выяснилось, что на одну загрузку страницы шли 47 последовательных запросов. Каждый быстрый, а вместе это 470 мс чистого ожидания.
Исправили одним SQL JOIN. Узкое место было в логике приложения, не в базе.
👉 @BackendPortal
Если увлекаешься технологиями, не пропусти True Tech Champ 21 ноября — масштабный ИТ-фест от МТС 🔥
В программе:
📝 доклады о технологиях будущего от экспертов в ИИ, включая руководителя фундаментальных исследований MWS AI Валентина Малых;
🛻 шоу-битва роботов со спецэффектами и сюжетной линией;
📝 воркшоп по работе с ИИ-агентами от канадского разработчика и автора книги AI Agents in Action Майкла Ланэма, кодинг-практикум с MWS AI и интеллектуальный спарринг с искусственным интеллектом;
◻️ 20+ площадок с активностями: IT-Родео, робофайтинг, лазерный лабиринт и многое другое.
🔴 А в завершение дня — афтепати со звездным хедлайнером.
Фестиваль бесплатный, он пройдет 21 ноября в Москве и онлайн.
Смотри подробную программу на сайте и регистрируйся — количество мест ограничено.
Запуск и управление контейнерами Docker
Изучите, как запускать контейнеры самых разных типов (серверы, базы данных, CLI-инструменты и т.д.), взаимодействовать с ними и сформировать чёткое понимание того, как Docker управляет вашими приложениями «под капотом».
Здесь: Docker 101: Run and Manage Containers
👉 @BackendPortal
Не все процессоры одинаковы.
На этом графике задержек показано сравнение апгрейда r6id → i7i.
Количество vCPU то же, объём RAM тот же, оба варианта используют локальные SSD.
И всё же переход на более новую инстанс-серию даёт заметный прирост производительности.
👉 @BackendPortal
Вот интересный трюк с UUID, про который знают немногие: UUIDv5.
В схемах баз данных обычно используют UUIDv7 как инкрементные первичные ключи или UUIDv4 для случайных идентификаторов. Но UUIDv5 почти не встречается, хотя в некоторых задачах он идеальное решение.
Представь ситуацию: пользовательские данные должны соответствовать требованиям GDPR. Пользователь запросил удаление аккаунта, мы стираем запись из таблицы users и все связанные записи по userId во внешних ключах. Позже пользователь подаёт жалобу в банк или Apple по старой транзакции, как нам найти его предыдущие операции, если userId уже нет?
Или, допустим, пользователь оформил подписку, потом удалил аккаунт и зарегистрировался заново, как реализовать обязательную для Apple функцию восстановления покупок?
Здесь и помогает UUIDv5.
При входе через OAuth2 мы можем связать (provider + openid + domain) и сгенерировать на их основе уникальный UUIDv5, назовём его accountToken.
В транзакциях мы передаём accountToken как идентификатор пользователя во внешние системы, вместо userId.
Если пользователь потом удаляет аккаунт, но позже снова входит тем же способом, генерируется тот же accountToken. Мы можем по нему найти старые данные транзакций и решить спор без восстановления личных данных.
Таким образом:
- соблюдается приватность и требования GDPR, личная информация пользователя действительно удалена;
- UUIDv5 accountToken обезличен и хэширован, обратное восстановление невозможно;
- при этом сохраняется возможность анонимного анализа и проверки транзакций (например, хранение истории 7 лет для финансовых и налоговых проверок).
Отличный баланс между комплаенсом и практической функциональностью.
Причина использовать UUID, а не просто склеивать строки и хэшировать их, в том, что Apple требует, чтобы accountToken, передаваемый при оплате, был в формате UUID. Кроме того, если взять домен приложения в качестве seed для UUIDv5 и объединить его с provider и openid, получается более стандартизированная и совместимая реализация.
👉 @BackendPortal