Микросервисы *

В интернете есть книги и множество статей, таких как эта, в которых авторы приводят аргументы в пользу использования Postgres для всего. Я решил рассмотреть один из вариантов использования — применение Postgres вместо Redis для кэширования. Я довольно часто работаю с API, поэтому я создал очень простой HTTP-сервер, который отвечает данными из этого кэша. Я начал с Redis, так как часто сталкиваюсь с этим на работе, а затем переключился на Postgres с использованием нежурналируемых таблиц и посмотрел, есть ли разница.

В мире микросервисов десятки, а то и сотни сервисов живут своей жизнью. Каждый со своим адресом, своими правилами, своей аутентификацией. Для внешнего клиента это выглядит как город без улиц и указателей. API Gateway — это попытка навести порядок. Он становится единым фасадом, центральным КПП для всего вашего бэкенда.

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

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

Перевести CRM-систему с тысячами пользователей на полностью российский стек — звучит как вызов? Мы тоже так подумали. Но теперь можем точно сказать: это возможно, и более того — это работает.

Команда Альфа-Банка с нашей поддержкой перенесла CRM-платформу, которую используют сотрудники в отделениях по всей стране, на Axiom JDK и контейнеризовала её с помощью Axiom Runtime Container.

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

Нормализация vs Денормализация: Mongo, Postgres и реальная жизнь. Почему у нас вырастает 160 таблиц там, где мог быть один jsonb? И как понять, когда денормализация — это костыль, а когда осознанный выбор?

Если при слове «нормализация» у тебя начинается зевота, а менеджер с порога предлагает «спроектировать базу» — этот текст для тебя.

Привет, Хабр! Каждый раз, создавая новый эндпоинт, я ловил себя на мысли: «А как назвать маршрут?». Казалось, что где-то есть законы и правила, которые помогают создавать API последовательно. Со временем я наткнулся на диаграммы по проектированию, прочитал книгу JJ Geewax — API Design Patterns (Джей‑Джей Гивакс), изучил рекомендации от крупных компаний и понял важную мысль: проектирование API — это такая же область знаний со своими принципами и стандартами.

Однако возникает проблема: стандарты есть, но они разные. Многие из них красивы на бумаге, но непонятно, как их применить в обычном CRUD‑приложении без сложной бизнес‑логики.

Цель статьи — дать компактную шпаргалку по проектированию API для простых CRUD‑сервисов и показать ход мыслей, который позволяет проектировать последовательно и осмысленно.

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

API — это не просто техническая прослойка. Это продукт. Его пользователи — другие разработчики. И, как у любого продукта, у него может быть ужасный или превосходный пользовательский опыт. Плохой API — это источник постоянной боли, багов и потраченного времени. Хороший API интуитивно понятен, предсказуем и прощает ошибки. Он становится продолжением мыслей разработчика.

Один неправильно «пришитый» IP — и рождается фантомная зависимость. Netflix на масштабе ≈5 млн TCP-потоков/с отказался от событийного учёта адресов и построил атрибуцию на наблюдаемых таймлайнах владения IP: eBPF-сайдкар точно метит локальную нагрузку (включая Titus и связку IPv6→IPv4 по паре IP+порт), а FlowCollector держит интервалы в памяти и рассылает их через Kafka, форвардя межрегиональные кейсы по trie из VPC-CIDR. Задержка — ~1 мин вместо 15, ложных совпадений — ноль по проверке на Zuul. В итоге flow logs стали источником истины о зависимостях и «здоровье» сети.

Великий аргентинский писатель Хорхе Луис Борхес в одном из своих произведений попытался доказать, что вся мировая литература сводится к четырем базовым сюжетам: история об осаде и защите обречённого города, история о возвращении, история о поиске и история о жертвоприношении или самоубийстве бога. В комментарий к этому заявлению Виктор Пелевин в одном из своих романов написал: «А по‑моему, сюжетов всего два. Первый — как человека убивают из‑за денег. Второй — как человека приносят в жертву. А на самом деле оба сюжета можно даже объединить в один». Как бы то ни было, оставим этот спор о сюжетах литературоведам. В этом же посте я хочу разобрать схожий тезис — все архитектуры разных видов программного обеспечения можно свести к двум базовым структурам — монолиту и шине.

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

Делюсь историей Новомира Лобанова, разработчика ИИ-решений для маркетинга, автоматизации и аналитики. Он запрограммировал ассистента на основе ChatGPT, чтобы упростить жизнь рекрутёрам. Процесс по шагам — в статье.

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

Хорошо спроектированный и надежный API — это ворота, через которые ваши данные и функциональность взаимодействуют с внешним миром: мобильными приложениями, веб‑сайтами, партнерскими сервисами и даже внутренними клиентами.

Предыдущая часть

Картина мира: почему браузер — главный блокер для «настоящего» gRPC

Если коротко, gRPC живёт поверх HTTP/2 и активно полагается на стримы. А в браузере до сих пор нет низкоуровневого API, который позволил бы JavaScript управлять HTTP/2‑стримами на том уровне, который нужен gRPC. Даже unary‑вызов в gRPC — это частный случай стрима: открыли поток, отдали запрос, забрали ответ, закрылись. Пока браузеры не дадут этот «рычаг», все WEB‑решения — это компромиссы разной степени изящности.

Чем это оборачивается на практике:

Нативные bidi‑стримы из браузера недоступны

Приходится конвертировать транспорт: HTTP/1.1 или WebSocket → что‑то «похоже на gRPC» → gRPC/HTTP2 на бэкенде

Добавляются прокси, адаптеры и слой совместимости, где теряется часть достоинств «чистого» gRPC

Ранее мы с вами развернули кластер Kafka. Что дальше?

В этой статье, как всегда, переходим от теории к практике: разработаем собственные продюсер и консьюмер на Python. Это будет не просто демонстрация кода — мы погрузимся в детали работы с Kafka.

Подробно разберем структуру сообщений Kafka,

Углубимся в основы проектирования: от топиков до настройки клиентов,

На практике изучим ключевые процессы: сериализацию, партиционирование, батчинг и сжатие данных.

Как построить микросервисы на RabbitMQ так, чтобы система не падала каскадом, а деградировала предсказуемо: outbox, mandatory, AE, идемпотентность, DLQ, приоритеты и реальные грабли из продакшена

Асинхронность в Python кажется простой — добавил async/await, и всё летает. Но на практике синхронные вызовы внутри асинхронного кода превращаются в «бутылочное горлышко», блокируя event loop и приводя к непредсказуемым последствиям: от подвисших запросов до деградации производительности. Как разбираться в таком случае и почему важно знать особенности фреймворков в подкате...

Magento — дорого, Ensi — сложно, Bitrix — просто. Или не так?

Всем привет! Я Роман, тимлид e-commerce агентства KISLOROD.

Платформа для интернет-магазина — стратегическое решение. Выбор между Bitrix, Magento и Ensi определит, насколько быстро вы запуститесь, сколько потратите на поддержку и сможете ли масштабироваться без боли. Разбираемся, что подойдет малому бизнесу, а что потянет высоконагруженный проект.

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

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

Привет, Хабр! Я Владислав Кислый, разработчик отказоустойчивых нагруженных сервисов в Т-Банке. Расскажу страшную сказку о том, как в одной компании взялись разрабатывать сервис. 

В качестве протокола взаимодействия выбрали gRPC. Что из этого вышло, с какими сетевыми проблемами пришлось столкнуться и как мы их решили — читайте в статье. Описанные проблемы можно потрогать руками с помощью тестового проекта, докера и темной магии Toxiproxy, который будет портить нам жизнь.