Когда начинают говорить о транзакциях в redis некоторым представляется в голове что‑то типа «postgresql»: «...Суть транзакции в том, что она объединяет последовательность действий в одну операцию „всё или ничего“. Промежуточные состояния внутри последовательности не видны другим транзакциям, и если что‑то помешает успешно завершить транзакцию, ни один из результатов этих действий не сохранится в базе данных...». Если говорить в ЭТОМ контексте, то транзакций в redis НЕТ и мы имеем дело с морской свинкой («не морская и не свинка»). А что же есть и как это можно мониторить.

Всем привет! На связи Максим Набоких, архитектор и технический руководитель Deckhouse Kubernetes Platform. Deckhouse работает в компаниях из разных отраслей: нефтегазовые предприятия, финтех, государственные организации, банки, облачные провайдеры и так далее. И больше чем в половине этих организаций во внутренней инфраструктуре нет интернета — он просто запрещён. Поэтому нам надо было придумать процесс установки своей платформы в закрытый контур.

О том, как устанавливать Kubernetes (Deckhouse использует ванильный K8s), где «не ступал» ни один пакет из публичной сети, я рассказал на HighLoad++ 2023. Эта статья — текстовая версия моего доклада. Мы разберём целевую схему закрытого контура, нюансы работы инструментов для создания безопасной среды, посмотрим, как готовить дистрибутив Kubernetes-платформы к установке и осуществлять доставку приложений в закрытых окружениях.

Если ваш сервис рассчитан на миллиарды пользователей, то несомненно возникнет вопрос о масштабировании.

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

В командах, особенно быстро растущих, конфликты — не редкость. И часто они возникают вовсе не из-за личных антипатий, а из-за размытой структуры полномочий.

Кажется, вот появился новый человек, чтобы помочь… но почему-то вместо облегчения становится только сложнее. Один руководитель — это порядок. Два — это борьба. Особенно если старый — «свой», а новый — новичок с инициативой.

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

Выбор подходящей системы управления базами данных (СУБД) — важнейшая задача при проектировании программных систем. Разработчики и архитекторы учитывают множество факторов: модель данных (реляционная или NoSQL), поддержку транзакций, масштабируемость, требования к согласованности и многого другое. Одним из ключевых архитектурных аспектов, влияющих на эффективность и надежность системы, является модель репликации данных. Репликация означает поддержание копий одних и тех же данных на нескольких узлах (серверах), соединённых по сети​.

Зачем это нужно? Репликация позволяет: во-первых, держать данные ближе к пользователям (уменьшая задержку при запросах); во-вторых, продолжать работу системы даже при сбое отдельных узлов (повышая доступность); в-третьих, масштабировать систему, увеличивая число узлов для обслуживания запросов на чтение (повышая пропускную способность)​.

Однако реализация репликации сопряжена с серьёзными архитектурными компромиссами. Согласно теореме CAP, в распределённой системе невозможно одновременно гарантировать все три свойства: консистентность данных, доступность сервиса и устойчивость к разделению сети. При возникновении сетевых сбоев (разбиении на изолированные сегменты) системе приходится жертвовать либо мгновенной согласованностью данных, либо доступностью части узлов. Поэтому разные СУБД делают разные выборы в этих компромиссах. Архитектурная модель репликации, лежащая в основе СУБД, определяет, как база данных достигает (или не достигает) консистентности, доступности и отказоустойчивости. Понимание этих различий крайне важно для архитекторов и разработчиков: зная поведение репликации, вы сможете выбрать такую СУБД, которая лучше соответствует требованиям вашего проекта по масштабу, геораспределенности, допустимой задержке и устойчивости к сбоям.

К сожалению, в последнее время всё больше и больше людей советуют использовать JWT для управления пользовательскими сессиями в веб-приложениях. Это ужасная идея, и в этом посте я объясню, почему.

Меня зовут Николай Кокоулин, я бэкенд-разработчик в Ви.Tech — это IT-дочка ВсеИнструменты.ру. В этой статье поделюсь нашим опытом о том, как мы в ходе разделения монолитного приложения на микросервисы столкнулись с вызовом: как сохранить производительность и масштабируемость системы при росте нагрузки.

Это статья описывает опыт миграции традиционного приложения java spring на Spring reactor стек. О специфике разрабатываемой информационной системы, уже подробно рассказывал. Кратко о системе - смешанная сервисно-микросервисная архитектура. Чтобы получить бизнес результат, требуется вызвать микросервис, который вызывает сервис, который вызывает набор микросервисов для формирования ценностного набора данных. Получается цепочка вызовов. Сервисы и микросервисы разрабатывались на традиционном технологическом стеке, без использования реактивного подхода.

Мое знакомство с реактивным подходом произошло в 2022 году. Плюсы и минусы я осознавал, как мог. В рамках разрабатываемой системы мне было сложно найти ему точку применения. Тогда сложилось понимание, что в существующих рамках реактивный подход не даст возможности эволюционных изменений. Если его применять, то применять ко всему и сразу, как постулирует реактивный манифест.  Даешь революцию! Это было заблуждение. Его я не смог разрушить, даже изучая документацию и статьи. Чего-то релевантного моей ситуации в открытых источниках я найти не мог. Этой статьей постараюсь предложить путь и убедить сомневающихся, что долго раздумывать не стоит. Делайте смелый шаг на пути к реактивному стеку.

Привет, Хабр! На связи Андрей Чернов, Java‑архитектор в СберТехе. В прошлой своей статье я рассказал про особенности работы с секретами в Java‑сервисах на Spring Boot — где их брать и как применять к вашему сервису, на примере того, как мы делаем это в Platform V Sessions Data.

Работа с секретами в современных реалиях, где ни с чем не интегрированных сервисов почти не осталось, очень важна. Она помогает снизить риски утечек и атак, а значит, сохранить деньги, время и репутацию компании. Секретами могу быть, например, сертификаты и учётные данные (имя пользователя, пароль и т. п.).

Как я уже говорил, файлы с секретами по разным причинам меняются, поэтому сервису нужно вовремя реагировать на это и применять новые секреты. В своём сервисе Platform V Sessions Data мы решили применять обновления секретов прямо «на горячую», не останавливая, не перезапуская сервисы, и даже не снимая с них нагрузку. Мы называем это hot reload.

Привет! Я Вероника, фронтенд‑разработчик, работала в корпорации и была человеком-оркестром в стартапе. В стартапе я как раз задумалась над темой развития карьеры по двум стратегиям: хайповой — поднимать зарплату раз в год через собеседования, и консервативной — то самое «думать с позиции бизнеса».

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

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

OnlyFans сегодня — это бизнес на $5.5B с 50% маржинальностью, который почти не тратится на маркетинг. Я вкратце расскажу про эволюцию порнографии за последние 40 лет, историю появления и причины успеха OnlyFans среди конкурентов, и сколько денег получают обычные девушки за свои откровенные фоточки. Важно: я не буду разбирать моральную сторону темы — сегодня мы будем использовать только сухие цифры и решения руководства, которые и создали феномен OnlyFans.

Аудитории Хабра наверняка интересно, какие вопросы задают на техинтервью в мультинациональных корпорациях. Ведь ИТ-индустрия была и остается глобальной, несмотря на геополитику и разные другие сложности. Как минимум, такая информация об интервью «из первых рук» — это ориентир по уровню сложности собеседования на позицию Java Lead в любых других компаниях, включая крупные российские банковские и промышленные структуры. Именно поэтому эта статья в нашем блоге SSP SOFT.

Команда Spring АйО перевела статью, в которой подробно рассматривается процесс регистрации и аутентификации пользователей с использованием Spring Security.

Всем привет! Я работаю на собственном проекте Максилекта. Это высоконагруженная AdTech платформа, включающая Ad Exchange сервер и сопутствующие компоненты. Но в этой статье речь пойдет не совсем о проекте. Я бы хотел поговорить об асинхронщине в задачах подобного масштаба. Просто на примеры из проекта мне будет удобно ссылаться. 

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

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

Эта статья предназначена для разработчиков, архитекторов и технических лидеров, которые ищут способы оптимизации производительности и масштабируемости своих систем. Она поможет понять:

Когда стоит использовать более простые подходы (например, шардирование, репликацию, CQRS) вместо того, чтобы сразу переходить к микросервисам.

Какие trade-offs возникают при выборе каждого из паттернов или архитектурных решений.

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

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

Всем привет! Сегодня мы посмотрим, как сделать полноценную интеграцию api шлюза spring cloud gateway и keycloak, так как мне показалось, что тема недостаточно раскрыта. С небольшими оговорками этот пример можно использовать в реальных продакшн условиях.