Backend Portal | Программирование

Правила выбора структур данных: * Небольшие коллекции (<100) → линейный проход быстрее HashMap (хэш + лишняя индирекция дороже, чем O(n)) * В основном чтение, записи редкие → иммутабельные структуры (JIT оптимизирует, нет рехэша, проще рассуждать о коде) * Высокая частота записей → избегай отсортированных структур (ротации деревьев добавляют скрытую стоимость) * Порядок нужен только на выходе → храни без порядка, сортируй при чтении (одна сортировка дешевле, чем поддерживать порядок всегда) * Частые итерации → оптимизируй локальность памяти (arrays > ArrayList > HashMap > TreeMap) * Hot path → избегай полиморфных структур (виртуальные вызовы мешают инлайнингу) * Стабильные ключи → заранее агрессивно задавай размер HashMap (resize = всплеск латентности) * Разреженные числовые ключи → массивы лучше мап (смещение по индексу быстрее хэширования) * Плотные enum-ключи → EnumMap (реализация на массиве, без хэширования) * Нужны и membership, и порядок → LinkedHashSet (платишь памятью, но избегаешь TreeSet) 👉 @BackendPortal

Бесплатный API для определения геолокации по IP-адресу. Безлимитные запросы и без регистрации. → ip․guide Подходит для JavaScript, Python, PHP и любого другого языка. 👉 @BackendPortal

Этот GitHub-репозиторий выглядит просто дико Это огромная подборка из 2600+ API для скрейпинга, с помощью которых можно вытаскивать данные с сайтов, соцсетей, e-commerce-платформ и много чего ещё. 👉 @BackendPortal

Kafka и NATS — это не просто два брокера, разница глубже: pull против push моделей. В Kafka консьюмеры сами тянут сообщения по оффсету и сами решают, когда читать. Это удобно для backpressure, батчевых задач и пайплайнов с частыми переигрываниями данных. В NATS всё наоборот: push-консьюмеры получают данные сразу по факту появления. Быстро, реактивно, без ощутимой задержки. JetStream позволяет смешивать подходы: push для широкого фан-аута, pull для контролируемых воркеров. Комбо, которое закрывает оба сценария. Но есть нюанс: push + медленный обработчик = тихий рост нагрузки в памяти. Держите под контролем max_ack_pending. Pull-режим в NATS отлично заходит для автоскейлинга воркеров: вытянули N сообщений → масштабируем поды дальше. Kafka: настройка max.poll.interval.ms важнее, чем кажется. Промахнулись — поймаете ребаланс и просадку по работе консьюмера. Общее правило: нужно стримить и переобрабатывать — берут Kafka. Нужны мгновенные реакции и низкая задержка — ближе NATS. 👉 @BackendPortal

Proxyman_App 6.3 для macOS добавляет поддержку HTTP/2, захват трафика на localhost для Chrome и Firefox, prettify для XML, новые команды в CLI, поддержку командных лицензий, определение IPv4-адресов, улучшенную проверку сертификатов и другие изменения. 👉 @BackendPortal

Когда стоит отказаться от классического ACID и 2PC и перейти к паттерну SAGA? Речь про микросервисы, где одна бизнес-операция (например, оформление заказа) проходит через кучу сервисов: Order → Payment → Inventory → Notification. → нет общей базы → нет распределённой транзакции → посреди процесса что-то падает: платеж прошёл, инвентарь не смог, нотификации отстрелялись частично В чём реальная проблема: Мы пытаемся добиться транзакционной согласованности между сервисами без глобальной транзакции. Локальные ACID-транзакции уже не спасают, как только мы пересекаем границы сервисов. Это и есть distributed transaction проблема. Решение: паттерн SAGA Разбиваем длинную бизнес-транзакцию на цепочку локальных шагов, у каждого есть компенсирующее действие. Как это работает: • каждый сервис делает свою локальную транзакцию • если шаг заваливается, предыдущие компенсируются (а не откатываются магически) • консистентность достигается не сразу, а со временем (eventual consistency) Есть два распространённых подхода: 1. Choreography — сервисы реагируют на события, без центра 2. Orchestration — координатор управляет всем сценарием Важно: • состояние SAGA хранится персистентно, не в памяти • нужны ретраи, таймауты и идемпотентность • без нормальной наблюдаемости/логирования будет боль Итог: SAGA — это про управление ошибками между сервисами, когда глобальных транзакций нет, а согласованность всё ещё нужна. 👉 @BackendPortal

Нашёл репозиторий, который реально помогает выбрать HTTP-фреймворк под Go. Там интерактивный гайд с 25 типовыми задачами — от роутинга до вебсокетов — причём каждый пример написан на разных движках: net/http, Chi, Gin, Echo, Fiber и Mizu. Изучаем 👉 @BackendPortal

На Stepik вышел курс по Linux Внутри 20+ модулей: от установки Linux и работы с файлами до сетей, прав, дисков, процессов, автоматизации на Bash и многого другого. Всё сразу закрепляется на практике (200+ заданий с автопроверкой) Материал подаётся понятным языком, шаг за шагом, на реальных примерах и с наглядными схемами. После прохождения вы получите сертификат, который можно добавить в резюме. Есть бесплатные демо-уроки для ознакомления. В ближайшие 48ч курс доступен со скидкой 25% по промокоду «HNY_LINUX»: открыть курс на Stepik P.S. Курс можно купить в подарок на Новый год

ORM на больших нагрузках — это скорее антипаттерн. Когда вы выходите на масштаб, большинство команд от них уходит, потому что абстракция между БД и языком так и не держится до конца. На проде с нагрузкой ORM почти всегда мешает использовать нативные оптимизации базы. А если вы уже пишете сырой SQL, чтобы обойти ограничения ORM, то проще сразу работать через prepared statements. Да, ORM скрывает сложность запросов, но именно из-за этого легко отправить в прод неэффективные N+1 запросы и даже не заметить. А потом дебажить это в продакшн-инцидент — тот ещё гемор ORM отстают от возможностей СУБД. Индексы, query hints, новые фичи — либо использовать неудобно (вспомните prefetch в Django ORM), либо поддержки просто нет. В итоге вы ограничены самым примитивным функционалом, который ORM вообще умеет, вместо того чтобы нормально раскрывать потенциал базы. На масштабе явные SQL-запросы проще, быстрее и легче оптимизировать. Когнитивные расходы на маппинг объектов в таблицы себя уже не оправдывают. Справедливости ради — ORM хороши для прототипов и быстрого выхода на рынок. В начале можно, но важно заранее иметь план, как потом от этого уйти. Говорю из опыта: звучит легко, а на деле — ух, не всегда так просто. 👉 @BackendPortal

Бесплатный API с моделями ИИ — без привязки карты. ✓ 1000 запросов в день к моделям OpenAI ✓ Есть Qwen 3, Kimi K2 и Llama ✓ Аудио, голос, reasoning и прочее Сервис называется Groq → http://groq.com 👉 @BackendPortal