Медленные системы не падают. Они умирают медленно.

Все помешаны на аптайме и корректности.
Но настоящая тихая угроза — это задержки.

- Они не выбрасывают ошибок.
- Подрывают доверие.
- Убивают конверсии.
- Перегружают зависимости.
- И превращают работающее приложение в скрытую катастрофу.

Жёсткая правда:
→ Если система слишком долго "падает", она уже не работает.

Но при этом большинство команд до сих пор живёт с такими настройками:

– Таймауты по умолчанию 30 секунд
– Отсутствие circuit breaker-ов
– Общие thread pool'ы на критических путях

Звучит знакомо?

Такой стек не масштабируется.
Он блокирует пользователей.
И тянет за собой остальные подсистемы.

Хочешь выдерживать реальную нагрузку?

Нужны три уровня защиты:

1. Timeout (ы) — отказывай быстро. Защищай пользователя.
2. Circuit breaker(ы)— останавливай каскадные сбои.
3. Bulkhead(ы) — изолируй повреждённые участки.

Дело не только в "быстром интерфейсе".
Это вопрос устойчивости архитектуры.

Представь это как аварийные выходы.
не "по желанию", не "было бы неплохо".
Oбязательные.

> Подробнее

👉 @BackendPortal

Microsoft только что создала AI-агента, который умеет дебажить ваш код.

Недавно Microsoft Research опубликовала с открытым исходным кодом Debug-Gym — среду, которая позволяет агентам на базе больших языковых моделей (LLM) отлаживать код.

Эти агенты могут автоматически ставить breakpoint-ы, инспектировать переменные и переписывать файлы, пока тесты не проходят успешно. Контекст на уровне репозитория запускается внутри Docker-контейнера, чтобы агенты не повредили вашу машину во время экспериментов.

Microsoft протестировала это с девятью разными LLM на трёх бенчмарках. Результаты улучшались во всех случаях, когда агенты имели инструменты для отладки.

Однако даже лучшие агенты решили меньше половины проблем из набора SWE-bench Lite.

Такой разрыв неудивителен. В тренировочных данных современных LLM практически нет примеров отладки. Эти модели никогда не обучались последовательному принятию решений, которое требуется при отладке.

Мы генерируем всё больше и больше кода, но генерация — это самая простая часть. Поддержка и исправление — сложнее всего. Дебаг — самая трудная задача.

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

Это неэффективно.

Это новый вид технического долга.

Microsoft планирует дообучить модели специально для поиска информации в процессе отладки.

Цель — разработать более лёгкую модель, которая будет предоставлять контекст для более крупной модели генерации кода.

Это можно воспринимать как retrieval-augmented generation, но применительно к отладке.

Проверьте инструмент: https://microsoft.github.io/debug-gym/

👉 @BackendPortal

Бесплатный API для получения полной информации об IP-адресе.

Без регистрации и каких-либо ограничений.

Работает с Python, JavaScript, Java, PHP, Go и другими языками.

Пример использования: http://api.ipquery.io/1.1.1.1

👉 @BackendPortal

Изучай почему работают алгоритмы, а не только как.

Вот 5 материалов от freeCodeCamp , которые реально стоят твоего времени:

1. Понимать, как работают алгоритмы — этого мало. Разберись, почему они работают именно так.

freeCodeCamp выпустил продвинутый курс по Python, который прокачает твои фундаментальные знания в области Computer Science.
Профессор Куанг Хао поможет развить алгоритмическое мышление и интуицию: как превращать абстрактную математику в работающий код.
В курсе — сортировки, алгоритмы "разделяй и властвуй", амортизированный анализ, мастер-теорема и многое другое.

Подключай голову и погружайся:
6-часовой курс на YouTube → https://freecodecamp.org/news/algorithm-analysis-deep-dive/

2. Учись проектировать через объектно-ориентированные паттерны на Java.

Интерактивный курс от профессора Computer Science Марка Махони.
Освоишь: Composite Pattern, Observer Pattern, Visitor Pattern и другие.

Интерактивный формат, всё по делу:
Курс → https://freecodecamp.org/news/object-oriented-design-patterns-with-java/

3. Глубокое погружение в AI-инженерию в облаке.

Инженер AWS Суман Дебнатх расскажет про LLM-эмбеддинги, Retrieval-Augmented Generation (RAG), мультимодальные модели и агентов на базе LangChain.
Соберёшь end-to-end приложение для автоматизации страховых кейсов: от создания заявки до управления документами и извлечения данных.
Задействуешь стек AWS, включая Bedrock.

6 часов плотной практики:
Курс на YouTube → https://freecodecamp.org/news/learn-enterprise-ai-embeddings-rag-and-multimodal-agents-using-amazon-nova-and-bedrock/

4. Подкаст недели: как превратить вклад в open source в работу.

Ник Тейлор, инженер из Монреаля и активный open source-контрибьютор, делится опытом:
— с чего начать в open source
— как использовать это как трамплин для трудоустройства
— как эффективно комбинировать AI-инструменты и проверенные OSS-библиотеки

Слушай или смотри (1 час):
Подкаст → https://freecodecamp.org/news/how-to-turn-open-source-into-a-job-with-nick-taylor-podcast-181/

5. Уже работаешь разработчиком и хочешь расти до Staff-инженера?

Подробный гайд от Shruti Kapoor о том, как перейти от Senior к Staff.
Она рассказывает о своём пути в Big Tech, о различиях ролей и о том, как реально выглядят промоушены.
Практические советы по подготовке и созданию сильного профессионального трека.
25 минут — и ты лучше понимаешь карьерную лестницу:

Статья → https://freecodecamp.org/news/how-to-get-promoted-from-senior-to-staff-engineer-tips-from-my-experience/

"Ключевой навык при работе с ИИ — это коммуникация.
Если не можешь чётко сформулировать, что нужно, инструмент будет выдавать мусор.
Так что софт-скиллы внезапно начали играть ключевую роль."
— Ник Тейлор, инженер-программист, в подкасте freeCodeCamp

👉 @BackendPortal

Как стать мастером продуктивности?

Используй несколько простых техник:

1. Фокусируйся на ОДНОМ.
Заблокируй слоты в календаре под каждую задачу и концентрируйся только на текущей.

2. Применяй правило 3:3:3:
- 3 часа — на приоритетные проекты
- 3 короткие задачи
- 3 рутинных/поддерживающих активности

3. Практикуй deep work минимум 4 часа в день без отвлечений.
Отключи телефон (режим «в самолёте»).

4. Метод Фейнмана при изучении нового:
- выбери тему
- объясни её «пятилетнему»
- найди и закрой пробелы в понимании

5. Используй матрицу Эйзенхауэра
Фокус на задачах, которые ведут к долгосрочным целям, ценностям и миссии.

6. Обрабатывай почту и сообщения пакетно
1–3 раза в день в конкретные временные окна.

7. Хочешь прокачаться в чём-то — 20 минут в день.
Через год ты будешь лучше, чем 90% остальных.

8. Используй методологию GTD (Getting Things Done)
для системного трекинга задач и действий.

9. Соблюдай правило Inbox Zero:
- Удаляй ненужные письма сразу
- Пересылай те, что требуют чужого внимания
- Отвечай сразу, если это займёт ≤ 2 минут
- Остальное планируй в задачник

10. Побеждай прокрастинацию с помощью Pomodoro:
- Задача → таймер на 25 минут → работа без отвлечений
- Короткий перерыв
- После 4 циклов — длинный перерыв

11. Планируй год / месяц / неделю / день.
Без цели нет направления.

12. Ежедневный и еженедельный ревью:
- Что сделал сегодня в соответствии с целями?
- Что можно улучшить?

13. Говори «НЕТ».
Одно «нет» = много «да» в других направлениях.

14. Ходи по 30 минут каждый вечер.
Лучше с практикой осознанности на ходу.

15. Автоматизируй всё, что можно.
Используй инструменты для избавления от повторяющихся задач.

👉 @BackendPortal

Предпосылки для деплоя

🔸Покрытие тестами и качество кода

Минимальное покрытие с проходящими unit-, интеграционными и e2e-тестами. Гарантирует, что код работает как ожидается.

- Базово: < 60% unit-тестов
- Хорошо: > 80% + интеграционные
- Отлично: > 90% + e2e

Инструменты: Jest, Cypress, SonarQube, Codecov

Без этого — риски:
- Прод ломается, UX страдает
- Экстренные хотфиксы и простои

🔸Сканы безопасности

Автоматическое сканирование уязвимостей в коде и зависимостях. Предотвращает доставку небезопасного кода.

- Базово: Dependency Check
- Хорошо: SAST + DAST
- Отлично: SCA + Secrets Scan

Инструменты: Snyk, SonarQube Security, OWASP ZAP, GitGuardian

Без этого — риски:
- Утечки данных, инциденты
- Проблемы с соответствием требованиям, юр. риски

🔸Тестирование производительности

Нагрузочное тестирование для проверки устойчивости под трафиком. Предотвращает деградацию в проде.

- Базово: Smoke-тест
- Хорошо: Load-тест
- Отлично: Stress + Chaos

Инструменты: k6, JMeter, Artillery, Gatling

Без этого — риски:
- Падение системы под нагрузкой
- UX страдает, потеря клиентов

🔸Health-чек

Эндпоинты, проверяющие готовность и живость приложения. Важно для балансировщиков и оркестраторов.

- Базово: HTTP 200 Check
- Хорошо: Health-чек
- Отлично: Dependency Health

Инструменты: Spring Actuator, Express Health, Kubernetes Probes, AWS ELB Health

Без этого — риски:
- Фейлы без rollback-триггера
- Трафик уходит на мёртвые инстансы

🔸Стратегия отката

Автоматизированный rollback для фейловых релизов. Критически важно для прода.

- Базово: Ручной откат
- Хорошо: Blue/Green
- Отлично: Canary + Auto

Инструменты: Blue-Green Deploy, Kubernetes Rollings, AWS CodeDeploy, Spinnaker

Без этого — риски:
- Долгий даунтайм
- Ручной откат может всё усугубить

🔸Мониторинг и алерты

Преднастроенные алерты на ключевые метрики и ошибки. Позволяет быстро найти проблемы после релиза.

- Базово: Basic метрики
- Хорошо: SLA алерты
- Отлично: Anomaly Detection

Инструменты: Prometheus, DataDog, New Relic, PagerDuty

Без этого — риски:
- Тихие фейлы, часами незаметные
- Жалобы от клиентов раньше, чем замечает команда

🔸Документация

Актуальные гайды по деплою, API-доки и runbook-и. Помогают при инцидентах и онбординге.

- Базово: README + API
- Хорошо: Deployment Guide
- Отлично: Полный Runbook

Инструменты: OpenAPI / Swagger, GitBook, Confluence, Notion

Без этого — риски:
- Затруднения при инцидентах
- Медленный онбординг и пробелы в знаниях

🔸Конфигурации и переменные

Конфиги окружений вынесены из кода. Предотвращает баги и утечки.

- Базово: Вшитые значения
- Хорошо: Config-файлы
- Отлично: External config service

Инструменты: Kubernetes ConfigMaps, AWS Parameter Store, Consul, etcd

Без этого — риски:
- Секреты в коде
- Баги и несоответствия между окружениями

🔸Стратегия миграции БД

Тестируемые миграции с планом отката. Предотвращает порчу данных при релизах.

- Базово: Ручные SQL-скрипты
- Хорошо: Автоматические миграции
- Отлично: Zero-downtime

Инструменты: Flyway, Liquibase, Django Migrations, Rails Migrations

Без этого — риски:
- Падение из-за несовместимой схемы
- Даунтайм при ручных миграциях

👉 @BackendPortal

Как обработать 1 миллион API-запросов в минуту

1. Балансировка нагрузки

Проблема:
Один сервер не выдерживает 1M запросов/мин: перегрузка CPU и памяти, начинается дроп запросов.

Решение:

- Использовать балансировщик нагрузки (NGINX, HAProxy, AWS ELB) для распределения трафика между множеством серверов
- Добавить проверки состояния , чтобы не направлять трафик на нерабочие инстансы
- Настроить авто-масштабирование, чтобы запускать новые инстансы при всплеске трафика

2. Кеширование

Проблема:
Каждый запрос бьет по базе → база становится узким местом (исчерпание соединений, медленные запросы).

Решение:

Добавить уровни кеширования:

- CDN для статических ресурсов (изображения, CSS, JS)
- Redis/Memcached для повторяющихся запросов
- Настроить правила инвалидации кеша, чтобы данные оставались актуальными

> Вместо 1M запросов к базе, возможно, только 100K дойдут после кеширования.

3. Ограничение частоты запросов

Проблема:
Всплеск активности (например, от ботов или злоумышленников) перегружает инфраструктуру → хорошие пользователи получают 503.

Решение:

- Алгоритмы Token Bucket / Leaky Bucket: позволяют короткие всплески, но сохраняют стабильный поток
- Разные лимиты для аутентифицированных и анонимных пользователей
- Возвращать 429 Too Many Requests — корректно и информативно

> Защищает инфраструктуру: один плохой пользователь не портит всё остальным.

4. Асинхронная обработка

Проблема:
Некоторые запросы тяжелые (обработка файлов, аналитика, отправка писем). Если делать их синхронно — ответ замедляется.

Решение:

- Выносить тяжёлые задачи в очередь (Kafka, RabbitMQ, SQS)
- Отвечать сразу с кодом 202 Accepted, обработку запускать в фоне
- Воркеры обрабатывают очередь и выполняют задачи

> Пользователи получают быстрый ответ, тяжёлая работа происходит «за кулисами».

5. Мониторинг и обратное давление

Проблема:
Даже при использовании балансировки, кешей и очередей, резкие всплески могут вызвать каскадные сбои.

Решение:

- Мониторить глубину очередей, задержки при доступе к БД, hit rate кеша
- Применять backpressure: замедлять запросы или отбрасывать нагрузку при приближении к лимитам
- Настроить алерты: Prometheus/Grafana, Datadog, New Relic

👉 @BackendPortal

Принес крутейший сайт для прокачки алгоритмов — визуальный тренажёр с пошаговым выполнением кода

70+ алгоритмов на JavaScript, Java и C++, всё интерактивно и с наглядной визуализацией

https://algorithm-visualizer.org/

👉 @BackendPortal

Что происходит при ввода адреса в браузере

👉 @BackendPortal

Проектирование системы потоковой музыки (Spotify) ✴️

🔸Системные требования

- 400M+ активных пользователей
- 100M+ песен
- 10M+ одновременных потоков
- 99.9% аптайм

🔸Ключевые функции:
- Высококачественный аудио-стриминг с адаптивными битрейтами
- Персонализированные рекомендации и поиск
- Создание и шаринг плейлистов
- Социальные функции (подписки на артистов и друзей)
- Оффлайн-доступ для премиум-пользователей
- Синхронизация и переключение между устройствами

🔸Архитектура высокого уровня

- User Service — аутентификация, профили, подписки
- Music Catalog — метаданные, поиск, просмотр
- Streaming Engine — доставка и адаптация аудио
- Recommendation — ML-алгоритмы и персонализация
- Playlist Service — создание, шаринг, коллаборации
- Analytics — трекинг и расчет роялти

Технологии:
Python, Java, PostgreSQL, Cassandra, Redis, Kafka, Elasticsearch, CDN, AWS

Поток воспроизведения музыки

🔸Шаг 1: Аутентификация и загрузка профиля

- Пользователь логинится — проверка учётных данных в user database
- Предпочтения и история прослушиваний из PostgreSQL
- Подписка определяет допустимое качество и функции
- Кэширование недавней активности в Redis

POST /auth/login → Валидация → Загрузка предпочтений → Кэширование в Redis

🔸 Шаг 2: Поиск и дискавери

- Поиск трека через Elasticsearch (fast text matching)
- Метаданные подтягиваются из Cassandra
- Recommendation engine предлагает похожие треки
- Быстрая загрузка обложек и треков по ID

Поисковый запрос → Elasticsearch → Получение метаданных → Генерация рекомендаций

🔸Шаг 3: Стриминг и адаптация качества

- Клиент запрашивает аудио → выбор ближайшего CDN edge-сервера
- Аудио подтягивается из распределенного хранилища
- Adaptive bitrate streaming на основе скорости сети
- Потоковые чанки передаются по HTTP

Запрос → CDN → Адаптивный битрейт → Потоковая передача чанков

🔸Шаг 4: Аналитика и роялти

- События прослушивания отправляются в Kafka (real-time)
- Взаимодействия хранятся в analytics database
- Расчет роялти на основе региона и стримов
- Данные возвращаются в ML recommendation models

Трекинг трека → Kafka → Хранение аналитики → Обновление рекомендаций

🔸Хранение данных

Выбор БД:
- PostgreSQL — профили, подписки, плейлисты
- Cassandra — каталог, метаданные, история
- Redis — сессии, кэш, ивенты
- AWS S3 — аудио, обложки, бэкапы

Стратегия партиционирования:
- Каталог по артистам/альбомам
- Данные пользователей по регионам
- История прослушиваний — time-series по дате

🔸Производительность и CDN

Доставка аудио:
- Глобальный CDN в 100+ локациях
- Поддержка форматов (MP3, AAC, OGG) и битрейтов
- Кэширование по популярности

Масштабирование:
- Микросервисы с независимым скейлингом
- Автоскейлинг по нагрузке
- Балансировка между дата-центрами

🔸Безопасность и лицензирование

Защита контента:
- DRM для премиум-контента
- Аудио-водяные знаки
- Аутентификация по токену
- Ограничение по частоте запросов

Конфиденциальность:
- Соответствие GDPR
- Шифрование персональных данных
- Анонимные рекомендации
- Безопасная оплата подписок

👉 @BackendPortal

Как не потеряться при выборе HTTP-статуса ответа

Запрос получен
  👇
Проблема с запросом?

Да:

➤ Запрос синтаксически корректен?
- Нет → 400 Bad Request
- Да →

➤ Путь найден?
- Нет → 404 Not Found
- Да →

➤ Аутентификация?
- Не передана или некорректна → 401 Unauthorized
- Передана, но нет прав доступа → 403 Forbidden
- Валидна →

➤ Запрос валиден (по схеме, типам, структуре)?
- Нет → 400 Bad Request
- Да →

➤ Есть ошибки в доменных данных (валидация бизнес-логики)?
- Да → 422 Unprocessable Entity
- Нет →

Успех:
- POST → 201 Created / 200 OK
- GET / PUT / PATCH → 200 OK
- DELETE → 204 No Content

Нет (проблем с запросом нет):

➤ Серверная ошибка?
- Да → 5xx Internal Server Error
- Нет →

➤ Ресурс существует?
- Нет → 404 Not Found
- Да →

Успех:
- POST → 201 Created / 200 OK
- GET / PUT / PATCH → 200 OK
- DELETE → 204 No Content

👉 @BackendPortal

Шаблон проектирования Facade

Сценарий: создание домашнего кинотеатра

Твоё приложение управляет подсистемами вроде DVD-плеера, проектора, аудиосистемы и освещения. Чтобы посмотреть фильм, сейчас тебе приходится напрямую вызывать множество шагов:

lights.dim();
projector.on();
dvdPlayer.insertDisc();
soundSystem.setSurround();
dvdPlayer.play();

Это работает, но код вызова получается сложным и повторяющимся.

Новые требования

Добавление новых фич (например, попкорн-машины) приводит к ещё большему количеству шагов. Другие разработчики или frontend-код должны знать все внутренности. Если изменится один шаг (например, прогрев проектора), придется обновлять код повсюду.

Проблемы

🔸Слишком много подсистем → вызывающий код должен знать все детали
🔸Повторяющиеся последовательности вызовов
🔸Сложно поддерживать: одно изменение ломает всё в разных местах
🔸Нет единой точки входа

Как помогает Facade

Facade создает единый упрощённый интерфейс, скрывая детали. Вместо множества вызовов ты просто пишешь:

theater.watchMovie();

Внутри Facade координирует свет, звук, проектор и т.д. Вызывающему коду не нужно знать «как» — только «что» он хочет.

До:
Много подсистем

👇

После:
Один Facade

Когда использовать

🔸Для сложных подсистем, которым нужен простой интерфейс
🔸Чтобы снизить связанность между клиентским кодом и деталями реализации
🔸При онбординге новых разработчиков: они работают только с Facade

Плюсы

🔸Упрощает использование и снижает связанность
🔸Облегчает поддержку и тестирование

Аналогия из реального мира

Приложение доставки еды

Ты заказываешь через один интерфейс (facade) а он под капотом управляет рестораном, доставкой и оплатой.

Минусы

🔸Может превратиться в "god object"
🔸Ограничивает тонкую настройку и контроль

👉 @BackendPortal

4 способа обновления данных в веб-приложении на стороне клиента в реальном режиме времени: коротки и долгий опрос, SSE и веб-сокеты

👉 @BackendPortal

Объяснение уровней кэширования

1. Кэш браузера
- Ближе всего к пользователю → минимальная задержка.
- Хранит: HTML, CSS, JS, изображения.
- Используется для повторных загрузок без обращения к серверу.

2. Кэш CDN
- Географически распределён, расположен между пользователем и вашим сервером.
- Кэширует:
- Статические ресурсы (изображения, скрипты, стили).
- Ответы API на GET-запросы.
- Снижает нагрузку на сервер и ускоряет доставку контента.

3. Кэш на уровне приложения (in-memory)
- Хранится в RAM.
- Может быть:
- Локальным на экземпляр приложения.
- В общей памяти (например, Redis, Memcached).
- Кэширует:
- Запросы к базе данных.
- Токены авторизации.
- Вычисленные результаты.

4. Кэш на уровне базы данных (внутренний)
- Встроенные механизмы СУБД.
- Кэширует:
- Результаты SQL-запросов.
- Индексы.
- Буферный пул для хранения страниц данных в памяти.

👉 @BackendPortal

Изучай разработку API с нуля

Этот БЕСПЛАТНЫЙ ресурс включает:

✓ Пошаговый курс по API REST и GraphQL
✓ Как добавить безопасность в свои API
✓ Лучшие практики и тестирование
✓ Монетизация API

→ http://rapidapi.com/learn

👉 @BackendPortal

Онлайн-система приёма платежей (Paypal/Stripe)

🔸Цели и требования
100M+ пользователей кошелька
1B+ транзакций в год
$500B+ объём платежей
99.99% точность

Ключевые фичи:
- Цифровой кошелёк для хранения средств
- P2P-переводы между пользователями
- Обработка платежей мерчантов
- Линк банковского счёта и карт
- Обработка возвратов и чарджбеков
- Соответствие KYC/AML
- Система разрешения споров

🔸Архитектура высокого уровня

Auth & KYC Service — онбординг пользователей, верификация личности.
Wallet & Ledger Service — двойная бухгалтерия, управление балансами.
Payments Orchestrator — маршрутизация в карточные и банковские сети.
Risk/Fraud Engine — реал-тайм детект мошенничества.
Disputes Service — управление чарджбеками.
Payouts Service — выплаты мерчантам.
Compliance & Reporting — AML-мониторинг, аудит логов.

Примеры двойной бухгалтерии:

P2P-перевод (₹100):
Дебет: кошелёк отправителя ₹100
Кредит: кошелёк получателя ₹100

Оплата мерчанту (₹100, комиссия ₹2):
Дебет: кошелёк покупателя ₹100
Кредит: кошелёк мерчанта ₹98
Кредит: счёт комиссий ₹2

🔸Высокоуровневый флоу

1. Онбординг и KYC
- Создать аккаунт с подтверждением email/телефона
- Верификация личности (ID, селфи, proof of address)
- Привязка банковского счёта или карты с микро-депозитами
- Оценка рисков и комплаенс-чек

Sign up → Verify identity → Link payment method → Risk assessment

2. Пополнение кошелька
- Пользователь инициирует пополнение с привязанной карты/счёта
- Платёжный процессор делает внешний запрос
- При успехе — кредит кошелька пользователя
- Леджер обновляет баланс

Charge card/bank → Verify funds → Credit wallet → Update ledger

3. P2P-перевод (атомарный)
- Проверка баланса отправителя
- Чек правил антифрода для обеих сторон
- Атомарная транзакция: дебет отправителя, кредит получателя
- Реал-тайм уведомления обеим сторонам

Check balance → Risk validation → Atomic transfer → Notify users

4. Платёж мерчанту
- Авторизация платежа (заморозка в кошельке)
- При доставке — захват платежа
- Выплата на баланс мерчанта (минус комиссия)
- Пакетная выплата на банковский счёт мерчанта

Authorize → Capture → Settle → Payout to merchant bank

5. Возврат/чарджбек
- Реверс исходных леджер-записей
- Корректировка балансов всех затронутых аккаунтов
- Работа с доказательной базой
- Автоматические уведомления и трекинг прогресса

Dispute initiated → Reverse entries → Collect evidence → Resolve

🔸Data Model

users — id, kyc_status, risk_score.
accounts — id, owner_id, type, currency.
ledger_entries — txn_id, account_id, debit, credit.
transactions — id, amount, status, idempotency_key.
payment_methods — user_id, tokenized_card, bank_link.
disputes — txn_id, phase, deadline, evidence.

Критические индексы:
(txn_id) для поиска.
(account_id, timestamp) для балансов.
(idempotency_key) уникальный.

🔸Безопасность и комплаенс

Фрод-превеншн:
- Лимиты частоты операций per user/device
- ML-анализ аномалий
- Device fingerprinting
- Поведенческий анализ

Комплаенс:
- Верификация KYC/AML
- PCI-DSS для данных карт
- Мониторинг транзакций
- Аудит логов (WORM)

Резервное управление:
- Риск-базовые резервы под чарджбеки
- Автоматические корректировки

🔸Стратегия масштабирования

Масштабирование леджера:
- PostgreSQL с партиционированием
- Append-only для неизменяемости
- Реплики для запросов по балансу

Консистентность:
- Сильная консистентность для леджера
- Идемпотентность для защиты от дубликатов
- Асинхронная обработка уведомлений

Техстек:
- PostgreSQL (точная работа с десятичными)
- Go/Java-сервисы
- Redis для кеша
- Kafka для асинхронных процессов

👉 @BackendPortal

Качество кода не появляется случайно.

Моменты, которые навсегда определили стандарты качества кода:

1987 – Принцип подстановки Лисков
Подтипы должны корректно работать везде, где ожидаются их родительские типы.

1988 – Принцип открытости/закрытости
Код должен легко расширяться без изменения уже существующего поведения.

1994 – Паттерны проектирования "Банда четырёх"
Общий словарь и проверенные структуры для решения типовых задач проектирования.

1999 – Рефакторинг
Книга Мартина Фаулера формализовала безопасное изменение кода как отдельную дисциплину.

2000 – Принцип разделения интерфейсов
Интерфейсы должны быть небольшими, чтобы классы реализовывали только то, что реально используют.

2003 – Принцип единственной ответственности и принцип инверсии зависимостей
Одна причина для изменения модуля; зависимости строятся на абстракциях, а не на конкретных реализациях.

2004 – Акроним SOLID
Пять принципов проектирования объединены в единую, легко запоминающуюся концепцию.

2005 – Предметно-ориентированное проектирование
Моделирование кода в соответствии с реальной бизнес-логикой и границами домена.

2008 – Чистый код
Код должен быть простым для чтения, понятным для рассуждения и безопасным для изменения.

2011 – Twelve-Factor App
Чёткая методология для построения переносимых, масштабируемых облачных сервисов.

2014 – Reactive Manifesto
Современные системы должны быть отзывчивыми, устойчивыми, эластичными и событийно-ориентированными.

2017 – TypeScript
Статическая типизация добавляет структуру и безопасность в крупные JavaScript-кодовые базы.

2018 – Инженерные практики Google
Читаемость кода, чёткая передача намерений и содержательные code review стали стандартом по умолчанию.

2019 – Чистая архитектура
Разделение бизнес-логики и фреймворков с помощью чётких слоёв и границ. (впервые опубликовано в 2017)

2023 – AI-ассистенты для написания кода
Дизайн и понятность кода стали важнее, чем когда-либо: ИИ пишет код, люди формулируют замысел.

Каждый из этих моментов изменил понимание того, что значит «хороший» код.

Сохраните этот список. Покажите его своей команде.
Если для вас важна поддерживаемость кода, вы стоите на плечах этих идей.

👉 @BackendPortal

Очень хорошая схема, суммирующая архитектуру Kubernetes

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

👉 @BackendPortal

Обязательные принципы проектирования solution architecture
(объяснение за 2 минуты или меньше)

7 ключевых принципов с практическими рекомендациями по проектированию решений

🔸Высокая доступность и устойчивость
↳ Высокая доступность гарантирует работу системы даже при сбоях, а устойчивость — быстрое восстановление.
↳ Используй active-passive или active-active failover, чтобы минимизировать простой. Закладывай избыточность и синхронизацию данных там, где нужно, чтобы сохранить работу сервиса при сбоях.

🔸Масштабируемость
↳ Система должна справляться с ростом нагрузки без падения производительности.
↳ Вертикальное масштабирование — добавление ресурсов в узел, но горизонтальное (добавление узлов) с балансировкой нагрузки даёт больше гибкости. Используй авто-масштабирование и управление состоянием (например, распределённые кэши), чтобы эффективно переживать пиковые нагрузки.

🔸Производительность
↳ Оптимизация производительности снижает задержки и повышает пропускную способность.
↳ Применяй non-blocking I/O, асинхронную обработку и кэширование для работы с конкурентными запросами. Используй p99 latency метрики для мониторинга худших сценариев и поддержания стабильного UX.

🔸Безопасность
↳ Безопасность должна быть встроена на всех этапах. Реализуй end-to-end шифрование, RBAC и threat modelling для проактивного снижения рисков. Используй OAuth2 или JWT для аутентификации, а также подход Zero Trust Architecture для постоянной проверки идентичности.

🔸Слабая связанность
↳ Модульные системы легче масштабировать и адаптировать.
↳ Используй event-driven архитектуру и асинхронные очереди (например, Kafka, RabbitMQ), чтобы разорвать жёсткие зависимости. Это повысит масштабируемость, отказоустойчивость и облегчит обновления.

🔸Расширяемость
↳ Системы должны безболезненно расти со временем.
↳ Следуй принципу open-closed, чтобы добавлять новые фичи без изменения базовой логики. Проектируй API-first и сохраняй обратную совместимость, чтобы поддерживать интеграции без сбоев.

🔸Повторное использование
↳ Переиспользуемые компоненты ускоряют разработку и повышают поддерживаемость.
↳ Думай о компонуемости, используй общие библиотеки, SDK и готовые компоненты. Применяй domain-driven design (DDD), чтобы переиспользовать решения в разных бизнес-доменах.

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

👉 @BackendPortal

Шардинг баз данных все что нужно знать

1. Что такое шардинг
Делим большую базу на несколько частей чтобы масштабироваться по горизонтали. Полезно когда одна БД уже не тянет чтение запись или хранение например миллионы юзерских записей.

2. Шард это кусок данных
Каждый шард это полноценная независимая БД которая держит часть общего набора. Пример пользователи с id 1..1M в шарде A и 1M..2M в шарде B.

3. Ключ шарда
Поле по которому решаем где хранить запись. Выбор ключа критичен для баланса и перфа. Пример user_id для базы пользователей.

4. Горизонтальное партиционирование
По сути то же что шардинг. Режем по строкам а не по колонкам. Пример клиентские данные по регионам US EU Asia.

5. Виды шардинга
Range based диапазоны id например 1..1M в одном шарде 1M..2M в следующем просто но есть риск хотспотов.
Hash based хеш функция распределяет записи по шардам убирает хотспоты но сложнее запрашивать диапазоны.
Geo based делим по географии даем локальным юзерам низкую задержку.

6. Карта шардов и роутинг
Сервис который знает в каком шарде живет запись. Пример таблица соответствий user_id и shard_host.

7. Решардинг
Меняем распределение данных когда шарды растут неравномерно или добавляем ноды. Без планирования боль возможен даунтайм и большие перетасовки данных.

8. Репликация в шардированной схеме
У каждого шарда все равно должны быть реплики для отказоустойчивости. Пример шард A имеет primary плюс две реплики для HA.

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

10. Когда лучше не шардинговать
БД спокойно помещается на одной ноде.
Чтение можно масштабировать репликами.
Запросы часто требуют джоинов между шардами.

🔸Примеры из практики

Facebook режет пользователей по user_id чтобы масштабироваться до миллиардов.
E commerce делит заказы по регионам чтобы снижать задержку.
Онлайн игры держат сессии игроков на разных игровых серверах.

🔸Лучшие практики

Выбирай ключ шарда который не создает хотспотов.
Держи размер шардов примерно равным.
Планируй решардинг с первого дня.
Используй консистентное хеширование если рост непредсказуем.

🔸Чего избегать

Кросс шард джоины по возможности убираем при необходимости денормализуем.

👉 @BackendPortal