15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Открыт набор в Т-Академию
Пройдите бесплатное обучение по аналитике или разработке на задачах, похожих на те, с которыми работают специалисты в крупных ИТ-компаниях.
В Т-Академии студенты каждую неделю выполняют практические задания и развивают собственный pet-проект. Приглашенные наставники из Т-Банка помогут прокачаться в одном из треков — разработке (backend, frontend, mobile) или в продуктовой аналитике.
Подойдет тем, кто уже знает базу, но не понимает, как применить ее на практике.
Учеба онлайн, можно совмещать с вузом или работой.
Помимо хардов — прокачка софт-скиллов, тренировочные интервью, мастер-классы и встречи в городах, где есть ИТ-хабы Т‑Банка.
У лучших будет шанс продолжить карьеру в команде.
Подать заявку можно до 31 июля
Наткнулся на крутой инструмент для визуализации JSON
jsoncrack.com — открытый проект, который превращает любой JSON в наглядную графовую диаграмму.
Идеально, если нужно быстро понять структуру вложенных данных или показать API-ответ заказчику.
➣ Репозиторий: github.com/AykutSarac/jsoncrack.com
Работает прямо в браузере, поддерживает импорт/экспорт, сохранение схемы и тёмную тему 😎
Подойдёт фронтам, бэкендерам и аналитикам.
👉 @BackendPortal
Большинство Go-разработчиков пишут обработчики без возврата ошибок (это считается стандартным способом) — они просто логируют ошибку или вызывают http.Error прямо внутри.
Но чище — позволить обработчикам возвращать ошибки и обрабатывать их централизованно. Это делает код более удобным для тестирования, читаемым и сопровождаемым. Вот компактный способ реализации
👉 @BackendPortal
💡 Как из идеи рождается робот, способный в одиночку инвентаризировать целый склад?
Почему команда отказалась от летающих дронов и рельсовых систем, а вместо них сделала автономного робота с десятью камерами? Какие неожиданные проблемы всплыли на этапе прототипирования и как их решали? И как не ошибиться, если вы тоже хотите создать что-то сложное с нуля? 🤔
В новой статье Вячеслав Гончарук, руководитель группы инженеров-конструкторов в Яндекс Роботикс, рассказывает про полный цикл разработки робота:
✅ От первой идеи и анализа рынка до ТЗ.
✅ Проверка концепции, макетирование и тесты.
✅ Секреты производства: от закупки деталей до финальной сборки.
Реальный опыт команды Яндекс Роботикс, который можно адаптировать под любую робототехническую задачу.
👉 Читаем здесь
Реклама. Рекламодатель ООО «Яндекс.Такси». ИНН 7704340310
Мои заметки по легендарной книге Clean Code.
Про-совет: чистый код это не чеклист, а образ мышления.
1. Оставляй код лучше, чем нашёл.
Даже мелкие улучшения со временем накапливаются.
2. Думай, прежде чем называть
Удачное имя кардинально улучшает читаемость.
Стремись к названиям, которые раскрывают намерение, легко произносятся и легко ищутся.
3. Функции ⇒
Избегай побочных эффектов.
Один уровень абстракции на функцию.
4. Комментарии должны добавлять ценность
Не пиши очевидное.
Единый стиль форматирования улучшает читаемость и снижает когнитивную нагрузку.
Введи гайд по стилю и придерживайся его.
5. Инкапсуляция ⇒
Делает код гибче и проще для изменений.
6. Fail Fast ⇒
Используй исключения для обработки ошибок.
Сообщения об ошибках должны быть информативными и помогать отладке.
7. Тестируемость — критически важна
Если код сложно протестировать — это тревожный сигнал о плохом дизайне.
8. Постоянно рефактори
Чистый код — это итеративный процесс.
➣ Участвуй в код-ревью — учись у других и делись опытом.
А говоря о код-ревью, как не вспомнить легенду — coderabbit (плагин в твоей айди, для ревью)
Регулярные и качественные ревью помогают находить ошибки и делиться знаниями в команде.
Если хочешь сделать ревью быстрее и содержательнее — CodeRabbit добавляет в твой workflow AI-ревью с учётом контекста, позволяя ловить баги раньше и держать кодовую базу в порядке
👉 @BackendPortal
Нашёл в Твиттере мощную подборку из 30 статей по системному дизайну — коротко, по делу, с примерами и кодом.
Можно читать по одной в день — хватит на месяц. Забирайте:
1. Что такое API
2. Что такое вебхуки
3. REST vs GraphQL
4. Что такое API Gateway
5. Балансировщики нагрузки
6. Алгоритмы балансировки нагрузки
7. Прокси vs Обратный прокси
8. Что такое масштабируемость
9. Что такое доступность
10. Как избежать единой точки отказа (SPOF)
11. Объяснение теоремы CAP
12. 15 типов баз данных и когда их использовать
13. 7 ключевых различий между SQL и NoSQL
14. Что такое ACID-транзакции
15. Подробное руководство по индексам в базах данных
16. Шардинг vs Партиционирование
17. Объяснение последовательного хеширования
18. CDC (Change Data Capture)
19. Кэширование
20. Топ-5 стратегий кэширования
21. 7 стратегий вытеснения кэша
22. CDN
23. Алгоритмы ограничения скорости
24. Очереди сообщений
25. Фильтры Блума
26. Идемпотентность в распределённых системах
27. Конкурентность vs Параллелизм
28. Stateful vs Stateless
29. Long Polling vs WebSockets
30. Пакетная (batch) vs потоковая (stream) обработка данных
Высокая доступность — это не удача, а результат проектирования.
Когда происходят сбои (а они обязательно произойдут), система останется доступной только в том случае, если ты это предусмотрел.
Именно здесь вступают в игру паттерны отказоустойчивости и репликации.
В этой статье автор разберёт:
✅Четыре типа отказоустойчивости: Active-Active, Active-Passive и гибридные схемы
✅Основные стратегии репликации: с одним лидером, с несколькими лидерами и без лидера
✅Компромиссы, которые нужно учитывать перед выбором подхода
Если ты действительно хочешь проектировать системы, способные переживать сбои без паники — это для тебя.
👉 Читать здесь: ccылка
👉 @BackendPortal
6 структур данных для экономии места в базе данных
Фильтр Блума
• Снижает стоимость поиска, проверяя, является ли элемент членом множества.
HyperLogLog
• Оценивает количество уникальных элементов.
Cuckoo filter
• Проверяет, принадлежит ли элемент множеству.
Minhash
• Находит сходство между множествами.
SkipList
• Эффективно ищет, вставляет и удаляет элементы из отсортированного списка.
Count-min sketch
• Находит частоту элементов в большом потоке данных
👉 @BackendPortal
Вещи, которые вы должны автоматизировать, но, вероятно, ещё не автоматизировали
• Резервные копии базы данных
— Плановые, протестированные и хранящиеся вне основной инфраструктуры — а не "когда вспомню".
• Удаление устаревших веток
— Очищайте старые Git-ветки как в локальном репозитории, так и в удалённом.
• Очистка просроченных feature-флагов
— Устаревшие флаги несут риски и путаницу — автоудаляйте их после завершения использования.
• Обновление зависимостей
— Используйте ботов вроде Dependabot или Renovate, чтобы избежать неожиданных сбоев.
• Скрипты настройки окружения
— Shell-скрипты или Dockerfile лучше пошаговых wiki-инструкций.
• Генерация release-заметок
— Автоматическая генерация на основе названий PR или сообщений коммитов.
• Provisioning инфраструктуры
— Используйте Terraform/CloudFormation вместо ручного управления через облачные консоли.
• Миграции схемы БД
— Применяйте версионированные миграции при деплое, а не вручную.
• Ротация и архивирование логов
— Не допускайте незаметного заполнения дисков.
• Продление SSL-сертификатов
— Не допускайте падения продакшена из-за просроченного Let's Encrypt.
• Алерты на аномальные паттерны
— Настройте оповещения не только на ошибки, но и на отсутствие запросов, логов или резкие всплески.
• Мониторинг Dead Letter Queue (DLQ)
— Алерты при непустом DLQ лучше, чем обнаружение проблемы через месяц.
• Отчёты об успешности Cron-задач
— Следите, если плановые задачи упали или вовсе не запускались.
• Отчёты о покрытии тестами
— Автоматически публикуйте результаты и статистику покрытия после каждого билда.
• Метки и назначение ревьюеров в PR
— Автоматизируйте триаж и назначение ответственных.
• Журналы передачи дежурства
— Автоматически отправляйте сводки или дашборды перед каждой ротацией.
• Анонимизация данных на стейджинге
— Автоматически очищайте прод-данные для использования в нижестоящих средах.
• Создание шаблона постмортема
— Запускайте шаблон и сбор таймлайна сразу после серьёзного инцидента.
• Slack- или email-нотификации о сбоях сборки
— Мгновенный фидбек лучше, чем осознание поломки спустя часы.
• Резервные проверки здоровья API
— Выявляйте нестабильные endpoint'ы, проверяя их из разных регионов.
👉 @BackendPortal
Никто вам этого не говорит, но идемпотентность это ещё и про время.
Когда большинство людей говорит об идемпотентности, они зацикливаются на уникальных ключах запроса.
Это важно, но настоящая точка влияния — это срок жизни этих ключей.
Если срок слишком короткий — пользователь может случайно оплатить дважды.
Если хранить их вечно — система раздувается от устаревших данных, которые никогда не понадобятся.
Рассмотрим, например, платежи:
Краткосрочная идемпотентность
Когда применять:
Если вы в основном имеете дело с временными ошибками, быстрыми сетевыми повторными попытками или двойными нажатиями кнопки "Оплатить" — краткосрочной достаточно.
Временные рамки:
Обычно от нескольких минут до часов. Это покрывает большинство автоматических ретраев и ручных ошибок пользователя.
Пример:
PayPal использует краткосрочную идемпотентность — если кто-то дважды нажмёт "Отправить", списание произойдёт только один раз.
Долгосрочная идемпотентность
Когда применять:
Для критичных операций — продление подписки, возвраты средств — когда запрос может быть случайно повторён спустя дни или даже недели.
Временные рамки:
Дни, недели, даже месяцы.
Пример:
PayPal может применять долгосрочную идемпотентность для продлений подписок или возвратов, чтобы избежать дублирующих списаний задним числом.
Идемпотентность — это в равной степени про доверие ко времени, как и к самому ключу.
Выберите срок жизни ключа в зависимости от значимости операции, затем отслеживайте и корректируйте.
Когда вы проектируете систему с правильным временным горизонтом — большинство граничных случаев исчезают.
Идемпотентность — это срок, настроенный под ваш бизнес.
👉 @BackendPortal
Это руководство сопоставляет топологии Kubernetes-кластеров от однозвёздочных (single-node) до гео-избыточных (geo-redundant), объясняя:
— кто их развёртывает
— как они масштабируются
— где они могут давать сбои
— и зачем каждая из них существует
👉 @BackendPortal
Выбор архитектуры может как усилить, так и разрушить вашу систему.
EDA vs REST — краткий справочник
🔹EDA (Event-Driven Architecture — событийно-ориентированная архитектура)
> Асинхронность: сервисы генерируют и обрабатывают события.
> Лучше всего подходит для: высокой масштабируемости, слабой связанности компонентов и реактивности в реальном времени.
> Типичные кейсы: IoT, обнаружение мошенничества, обработка заказов, стриминг данных.
🔹REST (Representational State Transfer)
> Синхронность: модель запрос–ответ по HTTP.
> Лучше всего подходит для: строгой согласованности, простоты и стандартных CRUD-операций.
> Типичные кейсы: публичные API, админки, доступ к ресурсам.
Предупреждения
> REST может не справляться с требованиями реального времени и динамическим масштабированием.
> EDA усложняет отладку, упорядочивание событий и работу с eventual consistency (поздней согласованностью).
Совет: эти подходы не взаимоисключающие.
Многие современные системы используют оба:
→ REST — для control plane
→ EDA — для data plane
Выбирайте инструмент под задачу. От этого зависит устойчивость вашей системы
👉 @BackendPortal
Изучай программирование, облачные технологии и DevOps на практике
Бесплатные серверы с реальными заданиями.
✓ Практикуй Git и работу с Linux-серверами
✓ Создавай и тестируй ресурсы AWS без риска
✓ Kubernetes, Docker, Terraform и другие инструменты
▶️Регистрация не требуется: https://kodekloud.com/pages/free-labs/
👉 @BackendPortal
Тихие убийцы в продакшн-системах
↳ Утечки памяти – Постепенно заполняют heap до тех пор, пока система не начнёт тормозить или не упадёт спустя часы или дни.
↳ Истощение пула потоков – Когда все потоки зависли или заняты, новые запросы просто «висят» молча.
↳ Неограниченные очереди – Бэклог накапливается, пока не будет съедена вся память или диск.
↳ Нееффективное логирование в горячих путях – Добавляет задержки и увеличивает использование диска, особенно под нагрузкой.
↳ Нагрузка на сборщик мусора – Частые или долгие паузы GC делают приложение неотзывчивым.
↳ Смещение времени – Несинхронизированные часы ломают аутентификацию, TTL, логи и распределённую координацию.
↳ Сбои DNS-резолвинга – Кэшированные ошибки DNS или «тихие» fallback-и могут нарушать внешние вызовы.
↳ Взрыв объёма логов – Избыточное логирование увеличивает затраты, перегружает системы логов или даже может крэшить приложения.
↳ Медленные запросы к БД – Не падают, но медленно деградируют производительность при росте трафика.
↳ Штормы повторных запросов – Ретраи при сбоях могут перегрузить систему и запустить лавинообразные отказы.
↳ Зависшие cron-задачи – Долго висящие или заблокированные задачи, которые не завершаются и не освобождают ресурсы.
↳ Заполнение диска – Сначала незаметно — пока приложение не сможет писать логи, кэш или чекпоинты.
↳ Зомби-процессы – Осиротевшие фоновые процессы, незаметно потребляющие CPU или память.
↳ Устаревший кэш – Возвращает неактуальные или некорректные данные, при этом внешне всё выглядит нормально.
↳ Пропущенные метрики или алерты – Мониторинг может молча перестать работать — и вы не узнаете, что что-то пошло не так.
↳ Нагретые шарды или очереди – Один shard получает весь трафик, что замедляет всю систему.
↳ Утечки неиспользуемых соединений – Не закрытые подключения к БД или HTTP медленно расходуют файловые дескрипторы.
↳ Случайные сбои внешних API – Внешние API могут время от времени отдавать 500 или timeout, но нечасто — чтобы сработал алерт.
↳ Неправильная настройка балансировщика – Неравномерное распределение трафика или залипающие сессии тихо режут производительность.
↳ Неэффективные health checks – Инстансы считаются здоровыми, даже если на деле они timeout-ятся или отдают ошибки.
↳ Медленный запуск зависимостей – Приложение поднялось, но БД или кэш готовы только через 30 секунд — из-за этого пользователи получают задержку.
↳ Несогласованные конфиги между окружениями – Незаметные отличия между dev/stage/prod могут вылезти багами только в проде.
↳ Разный ход часов в распределённой системе – Ломает leader election, TTL, истечение токенов и прочие критичные процессы — хоть и не сразу.
↳ Дрейф схемы – Старые версии сервиса работают с устаревшей схемой БД, из-за чего появляются тонкие баги.
↳ Долгие запросы, держащие ресурсы – Подвешивают потоки, подключения к БД и память — медленно снижая throughput под нагрузкой.
👉 @BackendPortal
🔓 Топ ошибок, которые совершают 9 из 10 программистов!
В Code Guard расскажут как выявлять и избегать ошибок, на которые ведутся даже опытные разработчики!
Микросервисы — лучшие практики
1. Проектируй с учётом сбоев
➟ Микросервисы должны быть устойчивы к сбоям на всех уровнях — от инфраструктуры до отдельных сервисов.
➟ Используй подходы вроде circuit breaker'ов, bulkhead-паттернов и graceful degradation.
2. Держи сервисы маленькими и сфокусированными
➟ Каждый микросервис должен быть спроектирован для выполнения одной задачи и выполнять её хорошо.
3. Используй лёгкие протоколы обмена данными
➟ Микросервисы должны взаимодействовать друг с другом с помощью лёгких протоколов, таких как REST, gRPC или очереди сообщений.
➟ Это снижает накладные расходы и повышает производительность.
4. Реализуй сервис-дискавери
➟ Сервисы должны уметь динамически находить и вызывать друг друга.
➟ Используй реестры сервисов вроде Consul или Eureka, либо DNS-базированное обнаружение.
5. Автоматизируй тестирование и деплой
➟ Микросервисы должны быть полноценно покрыты тестами и разворачиваться автоматически с использованием CI/CD и автотестов.
6. Децентрализованное управление данными
➟ Данные должны храниться в том сервисе, которому они принадлежат, а не в общей базе.
➟ Это снижает связанность между сервисами и позволяет им эволюционировать независимо.
7. Превентивный мониторинг
➟ Чтобы понимать, как работают сервисы, собирай и анализируй метрики: задержки, пропускную способность, ошибки.
➟ Используй Prometheus, Grafana и другие инструменты для отслеживания состояния и раннего выявления проблем.
8. Безопасность на всех уровнях
➟ Безопасность должна быть встроена на всех уровнях архитектуры: инфраструктура, сервисы, коммуникация.
➟ Используй SSL/TLS, OAuth2, JWT и другие проверенные подходы.
9. Централизованный логгинг
➟ Все логи должны агрегироваться в одном месте — это упрощает отладку и анализ инцидентов.
10. Стандартизация процессов разработки
➟ Установи общие стандарты: стиль кода, фреймворки тестирования, порядок деплоя.
➟ Это обеспечивает единообразие и снижает количество ошибок.
11. Используй контейнеризацию
➟ Применяй Docker и Kubernetes для упрощения развёртывания и масштабирования сервисов.
12. Внедряй паттерны устойчивости (resiliency)
➟ В дополнение к отказоустойчивому дизайну, реализуй retry-политики, кэширование, load shedding и прочие шаблоны повышения надёжности.
13. Асинхронное взаимодействие
➟ Используй событийно-ориентированную архитектуру для снижения связности и повышения масштабируемости.
14. Чётко определяй API
➟ Каждый сервис должен предоставлять чётко описанный и легко понимаемый API.
Что бы ты добавил к этому списку?
👉 @BackendPortal
🔥 Успех в IT = скорость + знания + окружение
Здесь ты найдёшь всё это — коротко, по делу и без воды.
Пока другие ищут, где “подглядеть решение”, ты будешь использовать самые передовые инструменты!
🖥 ИИ: t.me/ai_machinelearning_big_data
🖥 Python: t.me/pythonl
🖥 Linux: t.me/linuxacademiya
🖥 C++ t.me/cpluspluc
🖥 Docker: t.me/DevopsDocker
🖥 Хакинг: t.me/linuxkalii
🖥 Devops: t.me/DevOPSitsec
🖥 Data Science: t.me/data_analysis_ml
🖥 Javascript: t.me/javascriptv
🖥 C#: t.me/csharp_ci
🖥 Java: t.me/javatg
🖥 Базы данных: t.me/sqlhub
👣 GO: t.me/Golang_google
🖥 React: t.me/react_tg
👣 Rust: t.me/rust_code
🧠 Нейросети: t.me/vistehno
🖥 PHP: t.me/phpshka
🖥 Android: t.me/android_its
💼 Вакансии: t.me/addlist/_zyy_jQ_QUsyM2Vi
Я обожаю асинхронное взаимодействие. Оно масштабируемое, слабо связанное и отказоустойчивое.
Но потеря данных — это всегда моя проблема номер один.
Событийно-ориентированные системы выглядят просто на поверхности:
Вы публикуете событие. Другой сервис его подхватывает и что-то делает.
Но именно здесь данные и теряются:
> Публикатор отправляет событие... а потом падает до того, как брокер подтвердил приём.
> Консьюмер получает сообщение... и тоже падает до обработки.
> Консьюмер обрабатывает сообщение... но запись в БД молча фейлится.
Как это предотвратить?
1. Персистентные очереди + синхронная отправка
Заставьте брокера сохранить сообщение на диск до того, как он вернёт подтверждение.
Публикатор ждёт подтверждения — и только после этого продолжает работу.
2. Режим подтверждения на клиенте
Консьюмер подтверждает получение только после успешной обработки.
Если он упадёт в процессе — сообщение останется в очереди и попадёт в повторную доставку.
3. Поддержка "последнего участника"
Сообщение считается обработанным только после успешной записи в БД.
Если запись не удалась — ack не отправляется.
Асинхронность не риск.
Риск это игнорировать пограничные случаи.
Каждое сообщение — это обещание.
Либо выполняйте его, либо перезапускайте.
👉 @BackendPortal
Хеш-таблицы — это самая часто используемая структура данных в разработке ПО.
Они критически важны для быстрого доступа к данным, и каждый разработчик должен хорошо в них разбираться.
Три основные вещи, которые нужно о них знать: хеш-функции, как устроена хеш-таблица и как обрабатываются коллизии.
Если у тебя есть пробелы, я разложил всё по шагам:
1. Что такое хеш-функция?
Хеш-функция — это функция, которая принимает на вход любые данные и преобразует их в целое число.
Входные данные называются ключами, а результат всегда меньше заранее заданного значения.
Результат детерминированный: один и тот же вход всегда даёт одинаковое число.
С помощью хеш-функции можно преобразовать любой тип ключа в индекс массива.
2. Как устроена хеш-таблица?
Хеш-таблица — это комбинация хеш-функции и массива.
Она использует хеш-функцию для отображения ключей на значения заданного типа, хранящиеся в массиве.
Получившаяся структура данных неупорядочена: значения не сортируются по ключам и порядок вставки не сохраняется.
Кроме того, хеш-функция не гарантирует, что разные ключи будут отображены на разные индексы массива.
Когда два ключа отображаются в одну и ту же ячейку — происходит коллизия.
Коллизии необходимо обрабатывать, иначе ключи будут перезаписаны, и значения потеряются.
3. Как обрабатывать коллизии?
Существуют два основных подхода: цепочки и открытая адресация
Идея цепочки — хранить в массиве не значения, а связанные списки
Каждый список хранит пары ключ-значение всех ключей, отображённых на этот индекс массива.
Открытая адресация не использует дополнительные структуры данных и основана на поиске (probing).
Если возникает коллизия, ищется альтернативная позиция в массиве.
Альтернативная позиция может определяться фиксированным смещением или другой хеш-функцией.
Коллизии влияют на производительность хеш-таблиц, и их нужно минимизировать.
Хороший способ — выбирать размер массива простым числом.
Из-за коллизий основные операции с хеш-таблицами (вставка, удаление, поиск) имеют сложность O(N) в худшем случае.
При хорошей хеш-функции коллизии случаются реже, и эти операции работают в среднем за O(1).
👉 @BackendPortal
Как рефакторить легаси-код с помощью паттерна Strangler Fig
Паттерн Strangler Fig позволяет постепенно внедрять новую реализацию вокруг рискованного легаси-кода.
Мартин Фаулер ввёл эту метафору, наблюдая, как лианы оплетают дерево-хозяина и со временем его вытесняют.
Вместо рискованного «большого взрыва» ты оборачиваешь старый код тонким слоем, направляешь новый трафик на современную реализацию, и отключаешь легаси, когда покрытие достигает 100%.
Вот как "удушить" легаси пошагово:
1. Выдели тонкий интерфейс
Создай новый класс или адаптер с будущим API. Пока без переноса состояния — ты просто очерчиваешь контракт.
2. Перенаправь вызовы
Переориентируй контроллеры, сервисы или эндпоинты на новый интерфейс. Старый класс уходит на второй план.
3. Подними новый источник данных
Создай таблицу, топик или микросервис, который будет владеть извлечённым состоянием. В AWS и Azure это называют созданием target-boundary.
4. Двойная запись
В рамках одной транзакции пиши и в старое, и в новое хранилище. Это упрощает откат и позволяет сравнивать живой трафик.
5. Бэкфилл истории
Пакетно скопируй существующие строки. Блокируй записи или используй идемпотентные upsert'ы для консистентности во время миграции.
6. Переключи чтения
Переведи get-вызовы на новое хранилище. Мониторь ошибки и задержки; по необходимости — управляй через feature-флаг.
7. Удали легаси
Удаляй старые колонки, маршруты и тестовые фикстуры. Отпразднуй это зелёной сборкой и более простыми доками для новых разработчиков.
🚫 Big-bang рефакторинг выглядит героически, но часто превращается в проект-зомби.
✅ Паттерн Strangler Fig позволяет рефакторить безопасно, непрерывно приносить пользу и держать кодовую базу в чистоте на каждом спринте.
👉 @BackendPortal
ᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠ
ᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠ
ᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠ
ᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠ
ᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠ
ᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠ
Айтишники поймут
ᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠ
ᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠ
ᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠ
ᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠ
ᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠ
ᅠᅠᅠᅠᅠᅠ
ᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠᅠ
«Сокращалку ссылок написать — раз плюнуть, каждый второй пилил.»
Руководство по запуску и управлению собственным программным обеспечением и серверами дома или на работе — Self-Hosting-Guide
👉 @BackendPortal
6 способов масштабировать приложение от нуля до миллиона пользователей:
𝟭. Отдавайте статический контент через CDN
CDN распределяет статические ресурсы по edge-серверам по всему миру, снижая задержки на 40–60%. Это напрямую влияет на удержание и конверсию пользователей.
Кроме скорости, CDN обеспечивает защиту от DDoS и автоматические оптимизации, такие как сжатие изображений — всё то, что сложно реализовать самостоятельно.
𝟮. Распределяйте нагрузку между веб-серверами
Балансировщики нагрузки интеллектуально распределяют запросы между несколькими серверами, предотвращая узкие места и обеспечивая отказоустойчивость.
Современные балансировщики поддерживают session affinity, SSL-терминацию и health checks в реальном времени — это база для горизонтального масштабирования.
𝟯. Используйте лёгкие и быстрые контейнеры
Контейнеры упаковывают приложение с минимальными накладными расходами, позволяя запускать десятки экземпляров на одном сервере с почти нативной производительностью.
Kubernetes автоматизирует масштабирование: быстро поднимает новые инстансы при пике нагрузки и завершает их при спаде.
𝟰. Сначала получайте данные из кэша
Кэш-слои (Redis, Memcached) снижают нагрузку на базу данных на 80–90%, отдавая данные за микросекунды вместо миллисекунд.
Критически важна стратегия инвалидации — применяйте паттерны cache-aside или write-through в зависимости от требований к консистентности.
𝟱. Распределяйте нагрузку на БД
Мастер-слейв репликация разделяет операции записи и чтения, масштабируя чтение горизонтально при типичном соотношении 10:1.
Реплики чтения обеспечивают геораспределённость, но вносят eventual consistency, с которой нужно работать с учётом возможных лагов репликации.
𝟲. Используйте очереди и воркеры
Очереди сообщений отделяют обработку от ответа, предотвращая блокировку пользовательских взаимодействий из-за медленных операций.
Такая архитектура позволяет масштабировать компоненты независимо в зависимости от узких мест, оптимизируя производительность и расходы.
А какие у тебя самые большие челленджи с масштабированием? ♟
👉 @BackendPortal
9 лучших архитектурных паттернов для потоков данных и коммуникаций
👉 @BackendPortal
Концепты, которые кажутся неважными пока не сломаются
• Health Checks
— Без них балансировщики нагрузки продолжают слать трафик на упавшие сервисы.
• Retry Limits
— Бесконечные ретраи могут обрушить систему при сбое.
• Rate Limiting
— Поток запросов (даже от внутренних клиентов) может перегрузить систему.
• Circuit Breakers
— Предотвращают каскадные отказы, когда падают зависимости.
• Timeouts
— Нет таймаута → зависшие процессы → заблокированные потоки → мёртвая система.
• Idempotency
— Критична для избежания дублирования при повторных запросах от клиентов.
• Pagination
— Без неё API возвращает огромные ответы и душит клиентов.
• Monitoring
— Вы не узнаете, что сервис упал, пока кто-то/что-то за ним не следит.
• Alert Thresholds
— Плохо настроенные алерты создают либо шум, либо тишину — оба варианта опасны.
• Log Rotation
— Диск забивается. Приложение падает. Просто забыли про logrotate.
• Disk Space Alerts
— Вы узнаете, что диск переполнен, когда начнут фейлиться записи.
• Настройка TTL в DNS
— Неправильно сконфигурированный TTL приводит к устаревшим или недоступным сервисам.
• Clock Synchronization (NTP)
— Несинхронизированное время ломает токены, авторизацию, логи и распределённые системы.
• Environment Variable Management
— Опечатки или отсутствующие секреты ломают конфигурацию во время выполнения.
• Rollback Strategy
— Пожалеете, что её не было, когда деплой сломает production.
• Graceful Shutdown
— Без него выполняющиеся задачи/запросы убиваются посередине.
• Schema Migration Safety
— Ломающие изменения в БД, задеплоенные вслепую, кладут сервис.
• Dead Letter Queues (DLQs)
— Отсутствие DLQ означает, что сбойные сообщения просто исчезают.
• Dependency Version Pinning
— Неожиданное breaking-обновление испортит вам день.
• Feature Flag Cleanup
— Старые флаги порождают баги и путаницу между командами.
• Backup Testing
— Бэкапы бесполезны, если вы не проверяли восстановление из них.
• Load Testing
— Без него вы не узнаете пределы, пока трафик не обрушит систему.
👉 @BackendPortal
Дорожная карта для бекэндеров
Каждый пункт делится на градации junior, middle, middle+ (он же high middle)
Этапы и пункты выстроены в рекомендуемом порядке для изучения. Просто следуйте сверху-вниз
▶️https://github.com/bzick/oh-my-backend
👉 @BackendPortal
Как разработчику, тебе важно разбираться в базовых принципах системного дизайна.
Это показывает потенциальным работодателям, что ты умеешь превращать требования к архитектуре в продакшен-готовый код.
▶️Курс охватывает архитектуру приложений, проектирование API, кэширование, работу с сетью, базами данных и многое другое
👉 @BackendPortal
Управление серверами, базами данных и пользовательскими логинами это задача не из простых и может отнимать много времени.
Иногда гораздо удобнее использовать инструмент, который берёт всё это на себя. Тут на сцену выходит Backend as a Service (BaaS).
В этом гайде рассказывают, как работают BaaS-инструменты, в каких случаях они особенно полезны, какие решения сейчас популярны и с чего начать 🐸
👉 @BackendPortal
Пошаговое объяснение рабочего процесса Git
👉 @BackendPortal