Биллинговое решение для хостинг-компаний.

GitHub: https://github.com/Paymenter/Paymenter/

👉 @BackendPortal

Только что открыл для себя Resend Go SDK — пожалуй, самый чистый и удобный способ отправлять письма из Go-приложений.

Простой и понятный API
Строгая типизация, нативная поддержка Go
Встроенная поддержка шаблонов
Массовая отправка писем
Webhooks и трекинг доставляемости

Отлично подходит для транзакционных писем, уведомлений и не только. Больше не нужно возиться с настройками SMTP.

Заценить можно тут ❤️

👉 @BackendPortal

freeCodeCamp только что запустили бесплатную интерактивную программу, где можно изучить SQL и реляционные базы данных, а затем получить верифицированный сертификат для LinkedIn.

В курсе разобраны все ключевые темы. Практику можно делать в своем локальном редакторе кода, после чего пройти финальный экзамен.

Полный анонс и подробный FAQ здесь

👉 @BackendPortal

Превратите любой репозиторий GitHub в богатую, удобную для навигации документацию.

Просто замените «github» на «deepwiki» в URL-адресе репозитория.

👉 @BackendPortal

Сколько памяти на самом деле жрут структуры данных в Java (на один элемент):

int[] → 4 байта
Integer → ~16 байт
ArrayList<Integer> → ~24 байта
LinkedList<Integer> → ~48 байт
HashMap<K, V> → ~64–72 байта
TreeMap<K, V> → ~72–80 байт
ConcurrentHashMap → ~80–90 байт

👉 @BackendPortal

Нормализует контактные данные и блокирует временные почтовые домены.

https://github.com/GeKorm/better-auth-harmony/

👉 @BackendPortal

⭐️ Road to Highload: видеопроект о проектировании архитектуры высоконагруженных систем

Инженеры Яндекс 360 накопили значительный опыт в проектировании и разработке систем, которыми пользуются больше 95 миллионов человек ежемесячно.

В этом видеопроекте разработчики на практических примерах рассказывают, как создают архитектуру систем, которые держат 1 000 000 RPS и хранят петабайты мета-данных.

В выпусках обсуждаем:
🎙 Серия 1. Функциональные и нефункциональные требования. Как сбор требований помогает создавать надёжные и масштабируемые решения

🎙 Серия 2. Надёжный API. Принципы проектирования API, которые помогут сделать его консистентным, предсказуемым и поддерживаемым

🎙 Серия 3. Крупноблочная архитектура: карта вашей системы. Как выглядит модель на примере Яндекс Календаря и как ребята применяют её для эффективной коммуникации с различными командами разработки

🎙Серия 4. Практика: Рост баз данных: от единиц запросов к тысячам. Как правильно организовать работу с БД, чтобы система оставалась стабильной и эффективной

🎙 Серия 5. Практика. Взаимодействие со смежными системами. Типичные сложности, с которыми сталкиваются команды при интеграции с внешними сервисами, и как их предотвратить или минимизировать

Смотрите проект, чтобы узнать, как создаются одни из крупнейших облачных сервисов в России:

➕Сайт проекта
➕VK Видео
➕Ютуб

Популярные стратегии деплоя и ведения Git

» Feature Branch Workflow
Работа ведётся в отдельных фича-ветках, потом мёрдж в main через PR.

» GitHub Flow
Короткоживущие ветки, частые мёрджи, удобно для непрерывного деплоя.

» Git Flow
Структурированная модель: разработка, релизные ветки и хотфиксы.

» Trunk-Based Development
Минимальные ветки или прямые коммиты в main, упор на CI и стабильность.

👉 @BackendPortal

8 ключевых концепций в предметно-ориентированном проектировании

👉 @BackendPortal

Шаги SQL-запроса

Когда выполняется этот SQL-запрос, я представляю это так: каждая строка в запросе превращает одну таблицу в другую.

👉 @BackendPortal

Превращай сложные диаграммы по system design в интерактивные визуализации 🔥

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

👉 @BackendPortal

Не пропускай эти 6 задач по многопоточности перед собесом:

1. Producer-Consumer

Решай через BlockingQueue или wait/notify.

2. Печать 1-100 (2 потока)

Чередование через общий счетчик + lock/монитор.

3. Печать “ABCABC...”

Синхронизируй 3 потока через Lock или notifyAll.

4. Свой Thread Pool

Собери пул: воркеры + очередь задач.

5. Сценарий дедлока

Сымитируй и покажи, как избежать через порядок захвата локов.

6. Rate Limiter

Реализуй Token Bucket или Leaky Bucket.

👉 @BackendPortal

Давайте про вещь вроде бы очевидную, но с цифрами.

Теоретически и массивы, и связные списки проходят за O(n). Но если прогнать простой бенчмарк на суммирование 100k целых, получается так:

- массив: 68 312 нс
- связный список: 181 567 нс

Массив примерно в 3 раза быстрее. Алгоритм тот же, асимптотика та же, а разница в производительности огромная.

Причина в работе с кэшем. Когда мы читаем array[0], процессор подтягивает всю кэш-линию (64 байта). Это сразу захватывает элементы с array[0] по array[15]. Следующие ~15 обращений почти бесплатные. Попадания в кэш у массивов около 94%.

Со списками всё хуже: указатели, разрозненные аллокации через malloc(), ноды раскиданы по памяти. Каждое следующее значение может быть в другой кэш-линии, отсюда частые промахи и около 70% cache miss.

Это хороший пример, почему Big O — только часть картины. Пространственная локальность и дружелюбность к кэшу дают 2–3x разницу даже при одинаковой теоретической сложности.

Наверняка вы и так это знали, но такие цифры наглядно показывают, насколько выигрывают алгоритмы, дружные с кэшем.

👉 @BackendPortal

Бесплатный API с моделями ИИ — без привязки карты.

✓ 1000 запросов в день к моделям OpenAI
✓ Есть Qwen 3, Kimi K2 и Llama
✓ Аудио, голос, reasoning и прочее

Сервис называется Groq → http://groq.com

👉 @BackendPortal

ORM на больших нагрузках — это скорее антипаттерн.

Когда вы выходите на масштаб, большинство команд от них уходит, потому что абстракция между БД и языком так и не держится до конца.

На проде с нагрузкой ORM почти всегда мешает использовать нативные оптимизации базы. А если вы уже пишете сырой SQL, чтобы обойти ограничения ORM, то проще сразу работать через prepared statements.

Да, ORM скрывает сложность запросов, но именно из-за этого легко отправить в прод неэффективные N+1 запросы и даже не заметить. А потом дебажить это в продакшн-инцидент — тот ещё гемор

ORM отстают от возможностей СУБД. Индексы, query hints, новые фичи — либо использовать неудобно (вспомните prefetch в Django ORM), либо поддержки просто нет. В итоге вы ограничены самым примитивным функционалом, который ORM вообще умеет, вместо того чтобы нормально раскрывать потенциал базы.

На масштабе явные SQL-запросы проще, быстрее и легче оптимизировать. Когнитивные расходы на маппинг объектов в таблицы себя уже не оправдывают.

Справедливости ради — ORM хороши для прототипов и быстрого выхода на рынок. В начале можно, но важно заранее иметь план, как потом от этого уйти.

Говорю из опыта: звучит легко, а на деле — ух, не всегда так просто.

👉 @BackendPortal

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

Изучаем

👉 @BackendPortal

Когда стоит отказаться от классического ACID и 2PC и перейти к паттерну SAGA?

Речь про микросервисы, где одна бизнес-операция (например, оформление заказа) проходит через кучу сервисов:
Order → Payment → Inventory → Notification.

→ нет общей базы
→ нет распределённой транзакции
→ посреди процесса что-то падает: платеж прошёл, инвентарь не смог, нотификации отстрелялись частично

В чём реальная проблема:

Мы пытаемся добиться транзакционной согласованности между сервисами без глобальной транзакции.
Локальные ACID-транзакции уже не спасают, как только мы пересекаем границы сервисов.
Это и есть distributed transaction проблема.

Решение: паттерн SAGA

Разбиваем длинную бизнес-транзакцию на цепочку локальных шагов, у каждого есть компенсирующее действие.

Как это работает:
• каждый сервис делает свою локальную транзакцию
• если шаг заваливается, предыдущие компенсируются (а не откатываются магически)
• консистентность достигается не сразу, а со временем (eventual consistency)

Есть два распространённых подхода:

1. Choreography — сервисы реагируют на события, без центра
2. Orchestration — координатор управляет всем сценарием

Важно:
• состояние SAGA хранится персистентно, не в памяти
• нужны ретраи, таймауты и идемпотентность
• без нормальной наблюдаемости/логирования будет боль

Итог: SAGA — это про управление ошибками между сервисами, когда глобальных транзакций нет, а согласованность всё ещё нужна.

👉 @BackendPortal

Открытый, лёгкий аналог Supabase/Firebase с аутентификацией, UI для базы данных и хранением медиа, заточенный под работу в Next.js, React Router, Astro, Cloudflare, Node и других средах.

https://alternativeto.net/software/bknd-io/about/

👉 @BackendPortal