12073
Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика Связь: @devmangx РКН: https://clck.ru/3H4WUg
Как опытный Java-разработчик/бэкенд-инженер, ты должен разбираться в отказоустойчивости и паттерне Circuit Breaker. Вот сценарий ненадёжного платёжного шлюза 💳 , чтобы проверить знания кандидата:
Сценарий:
Твоё приложение интегрируется со сторонним платёжным API. При пиковых нагрузках этот API стабильно даёт сбой примерно в 2% запросов. Это приводит к неудачным оплатам и ухудшает пользовательский опыт.
Вопрос:
Как ты спроектируешь интеграцию так, чтобы она была устойчива к этим сбоям и при этом сохраняла хороший UX? Объясни, какие именно паттерны (например, Circuit Breaker или Retry с экспоненциальной задержкой) ты бы применил и почему. Как бы ты обработал возможные дубликаты транзакций, возникающие из-за повторных запросов?
→ Что я оцениваю:
Понимание паттернов устойчивости и отказоустойчивости. Кандидат должен уметь объяснить такие концепции, как повторные запросы, Circuit Breaker (например, с использованием Resilience4j), fallback-механизмы, а также критическую важность идемпотентности при проектировании интеграций с платёжными системами.
В примере показано как реализовать Resilience4j с fallback-методом в Spring Boot
👉 Java Portal
Принципы проектирования программного обеспечения 👇
[1.] KISS (Keep It Simple, Stupid)
▶Программное обеспечение должно быть максимально простым.
▶Используйте понятный и лаконичный код, избегайте излишней сложности и сосредотачивайтесь на основных функциях.
[2.] DRY (Don't Repeat Yourself)
▶Код не должен дублироваться.
▶Используйте функции и классы для объединения общего кода.
▶Применяйте переменные и константы для хранения значений, которые используются в нескольких местах.
[3.] YAGNI (You Ain't Gonna Need It)
▶Не добавляйте в программное обеспечение функции, которые не нужны.
▶Поддерживайте простоту и удобство сопровождения.
[4.] SOLID
▶ Принцип единственной ответственности – класс должен выполнять только одну задачу.
▶ Принцип открытости/закрытости – классы должны быть открыты для расширения, но закрыты для изменения.
▶ Принцип подстановки Барбары Лисков – объекты дочернего класса должны заменять объекты базового класса без нарушения функциональности.
▶Принцип разделения интерфейса – клиенты не должны зависеть от методов, которые они не используют.
▶Принцип инверсии зависимостей – зависимости должны внедряться в класс, а не быть жёстко закодированными.
[5.] Принцип наименьшего удивления**
▶ Разрабатывайте программное обеспечение так, чтобы оно соответствовало ожиданиям пользователя.
▶ Используйте знакомую терминологию и соглашения, предоставляйте понятные инструкции.
▶ Применяйте четкие и лаконичные сообщения об ошибках.
[6.] Принцип модульности**
▶ Проектируйте программное обеспечение как набор независимых модулей.
▶ Это упрощает понимание, сопровождение и тестирование кода.
[7.] Принцип абстракции
▶ Скрывайте детали реализации от пользователя.
▶ Это делает программное обеспечение более понятным и удобным.
[8.] Принцип инкапсуляции
▶Программное обеспечение должно скрывать внутреннее состояние объекта от внешнего мира.
▶Это повышает устойчивость и удобство сопровождения.
[9.] Принцип наименьшего знания
▶ Проектируйте программное обеспечение так, чтобы минимизировать объем знаний модуля о других модулях.
▶ Это помогает повысить модульность и гибкость системы.
[10.] Принцип низкой связности и высокой когезии
▶Связность – это степень зависимости элементов модуля друг от друга.
▶Модуль с низкой связностью имеет мало зависимостей, и его элементы слабо зависят друг от друга.
❗ Когезия – это степень, с которой элементы модуля относятся к одной цели.
▶ Модуль с высокой когезией имеет одну четко определенную задачу, и все его элементы связаны с её выполнением.
👉 Java Portal
Я только что наткнулся на этот репозиторий — и он отличный.
Хотите самостоятельно хостить OAuth 2.0-аутентификацию и не зависеть от Auth0, Clerk, Firebase или Supabase?
Тогда OpenAuth — именно то, что вам нужно.
Это универсальный провайдер аутентификации на основе стандартов, который можно полностью развернуть в собственной инфраструктуре.
Он работает с любым фреймворком и на любой платформе, а также совместим с любым OAuth 2.0-клиентом.
Главные возможности:
Полная поддержка OAuth 2.0 — его может использовать любой OAuth-клиент.
Гибкое развёртывание: Node.js, Bun, AWS Lambda или Cloudflare Workers.
Нативная поддержка Google, GitHub и других провайдеров, а также локальных сценариев: email и пароль, PIN-код и другие.
Готовый интерфейс, который можно полностью настроить или заменить собственным.
Полный контроль над управлением пользователями: через простой callback success можно реализовать собственную логику создания и поиска пользователей.
Лёгкое хранилище на основе KV, включая Cloudflare KV и DynamoDB.
Типобезопасный API и простая интеграция.
Сис. дизайн: Балансировщик нагрузки
Балансировщик нагрузки равномерно распределяет входящий трафик между веб-серверами, объединёнными в балансируемую группу.
- Пользователь подключается напрямую к публичному IP-адресу балансировщика нагрузки. При такой схеме клиенты больше не могут обращаться к веб-серверам напрямую.
- Это повышает безопасность: для взаимодействия между серверами используются приватные IP-адреса, недоступные из интернета.
- Балансировщик нагрузки взаимодействует с веб-серверами через приватные IP-адреса.
Добавив второй веб-сервер, мы устранили проблему отсутствия отказоустойчивости и повысили доступность веб-уровня.
- Если сервер 1 выйдет из строя, весь трафик будет перенаправлен на сервер 2. Это не позволит сайту стать недоступным.
- Если трафик сайта резко вырастет и двух серверов окажется недостаточно, балансировщик нагрузки позволит корректно решить эту проблему. В пул можно добавить дополнительные веб-серверы, после чего балансировщик автоматически начнёт направлять запросы и на них.
Вертикальное и горизонтальное масштабирование
Вертикальное масштабирование, также называемое scale up, — это процесс увеличения мощности серверов: добавления CPU, оперативной памяти и других ресурсов.
Горизонтальное масштабирование, также называемое scale out, позволяет масштабировать систему за счёт добавления новых серверов в пул ресурсов.
При низкой нагрузке вертикальное масштабирование может быть хорошим вариантом, а его главное преимущество — простота.
Ограничения вертикального масштабирования
- Невозможно бесконечно добавлять CPU и память одному серверу.
- Отсутствует отказоустойчивость. Если сервер выходит из строя, сайт или приложение полностью перестаёт работать.
Для крупномасштабных приложений горизонтальное масштабирование обычно предпочтительнее из-за ограничений вертикального масштабирования.
Если множество пользователей одновременно обращаются к веб-серверу и нагрузка достигает его предела, пользователи сталкиваются с увеличением времени ответа или вообще не получают ответ.
Эта проблема решается с помощью горизонтального масштабирования и балансировщика нагрузки.
👉 Java Portal
Java Streams: limit(n) превращает бесконечный поток в конечный.
✅ Полезно при работе со Stream.iterate() / generate() — они могут создавать бесконечные потоки
✅ limit(5) означает: «взять первые 5 элементов и остановиться»
✅ Отлично подходит для выборки данных или получения первых N значений
#Java #Streams
👉 Java Portal
Databasement — это инструмент для управления резервными копиями баз данных через self-hosted веб-интерфейс.
👉 Java Portal
Системный дизайн: Архитектура с одним сервером
Проектирование системы, способной обслуживать миллионы пользователей, — сложная задача. Это долгий путь, требующий постоянной доработки и непрерывного улучшения.
Обычно всё начинается с простого варианта: все компоненты работают на одном сервере.
Посмотрим, как проходит запрос:
> Пользователь обращается к api.mysite.com через веб-приложение или мобильное приложение.
> DNS преобразует доменное имя в IP-адрес 27.220.30.232.
> Запрос поступает на единственный веб-сервер.
> Сервер выполняет всё самостоятельно:
обрабатывает API-запрос;
выполняет бизнес-логику;
обращается к базе данных.
> Сервер отправляет пользователю HTML-страницу или JSON-ответ для дальнейшего отображения.
👉 Java Portal
> 💡 Java: Тестируйте граничные случаи: null, пустые коллекции и предельные значения — именно там чаще всего скрываются баги.
✅ Одних тестов счастливого пути недостаточно — они не помогут выявить NullPointerException при отсутствии входных данных.
✅ Пустые списки и коллекции с одним элементом нередко ведут себя иначе, чем коллекции с «обычными» данными.
✅ Явные тесты для null, пустых коллекций, а также минимальных и максимальных значений документируют ожидаемое поведение.
#Testing
👉 Java Portal
Архитектура Docker
Если вы только начинаете работать с Docker, эта схема может показаться сложной.
Но на самом деле всё устроено довольно просто.
Вы вводите команду, например:
docker run nginx
Вы
│
▼
Docker Client
│
▼
Docker Daemon
│
▼
Docker Image
│
▼
Docker Container
Создавайте первоклассную документацию для своего API или проекта.
Starlight предлагает всё необходимое: высокую скорость благодаря Astro, встроенную оптимизацию для SEO, доступность и поиск, а также поддержку Markdown, MDX и нескольких языков.
→ http://starlight.astro.build/es
👉 Java Portal
Масштабирование базы данных и стратегии шардинга — простое объяснение с иллюстрациями
По мере роста приложения или системы база данных тоже должна масштабироваться, чтобы справляться с увеличивающейся нагрузкой. Ниже — обзор основных стратегий.
1. Горизонтальное масштабирование (Horizontal Scaling)
Добавление новых серверов для распределения нагрузки и увеличения общей производительности без перегрузки одного сервера.
2. Вертикальное масштабирование (Vertical Scaling)
Увеличение ресурсов существующего сервера — процессора, оперативной памяти или дискового пространства — чтобы он мог обрабатывать больше запросов.
3. Стратегии партиционирования (Partition Strategies)
Логическое разделение большой базы данных на части (например, по времени, региону или типу данных), что упрощает управление и ускоряет доступ к данным.
4. Шардинг по диапазонам (Range-Based Sharding)
Данные распределяются между шардами по диапазонам значений (например, по цене, дате или идентификатору), что ускоряет поиск по таким полям.
5. Равномерное распределение данных (Even Distribution)
Нагрузка равномерно распределяется между всеми серверами, что позволяет максимально эффективно использовать ресурсы и избегать узких мест.
6. Неравномерное распределение данных (Uneven Distribution)
Нагрузка распределена неравномерно: одни серверы перегружены, а другие практически простаивают, что снижает эффективность всей системы.
7. Шардинг по ключу (Key-Based Sharding)
Для распределения данных между шардами используется хеш-функция, которая обеспечивает стабильное и равномерное распределение записей.
8. Масштабирование операций чтения (Scaling Reads)
Создание нескольких реплик базы данных только для чтения (Read Replicas), чтобы обрабатывать большое количество запросов и снизить нагрузку на основную базу данных.
9. Монолитная база данных vs шардинг (Monolith vs Sharding)
Вместо одной большой монолитной базы данных данные разделяются на логические шарды. Такой подход облегчает масштабирование системы, упрощает организацию данных и повышает производительность.
Эти подходы являются основой проектирования масштабируемых систем и часто используются при разработке высоконагруженных приложений и при подготовке к техническим собеседованиям по System Design.
👉 Java Portal
В PostgreSQL varchar(255) ведёт себя так же, как столбец типа text; единственное отличие — у varchar есть ограничение на длину. Тип varchar(n) всегда работал именно так. Если вы видите в PostgreSQL столбец varchar(255), то зачастую это потому, что разработчик сначала работал с другой СУБД и перенёс свои прежние представления о том, как должен работать varchar(n).
Когда использовать text, а когда varchar?
Если есть бизнес-требование ограничить максимальную длину значения или столбец индексируется с помощью B-tree, стоит рассмотреть varchar(n). Если такого требования нет — используйте text и не думайте, что делаете что-то неправильно.
Более того, в документации PostgreSQL говорится:
Хотя в некоторых других СУБД тип character(n) может иметь преимущества по производительности, в PostgreSQL таких преимуществ нет. Более того, character(n)
обычно является самым медленным из трёх вариантов из-за дополнительных затрат на хранение. В большинстве случаев вместо него следует использовать text или character varying
varchar(n) на text ничего не стоит?pg_attribute, поэтому изменение типа сводится к обновлению записи в этой таблице. Сами данные остаются без изменений, поэтому не требуется ни переписывать таблицу, ни менять формат хранения.char всё иначеchar на text для каждого значения выполняется rtrim, поскольку неявное приведение char к text автоматически удаляет завершающие пробелы.varchar(n), и text используют один и тот же механизм хранения, включая TOAST.varchar(n)?varchar(n), когда ограничение длины — это бизнес-правило, которое должна контролировать сама база данных. Например:country_code varchar(2), -- ISO 3166-1
currency_code varchar(3), -- ISO 4217
us_zip_code varchar(5), -- 5 цифр
sku varchar(20), -- ограничения внешних систем
varchar для country_code и currency_code? Конечно. Международные стандарты жёстко определяют длину этих кодов.SKU ограничение длины также может диктоваться внешними требованиями.us_zip_code, то на практике нередко возникает необходимость поддерживать расширенный формат ZIP+4. Со временем такие столбцы вообще могут быть переименованы в postal_code, чтобы поддерживать международные почтовые индексы.varchar одновременно обеспечивает и необходимое ограничение, и достаточную гибкость.varchar помогает обеспечить соблюдение бизнес-правил.varchar(n)text не является проблемой, однако есть нюанс.varchar(n) может служить дополнительной защитой для индексируемых столбцов (например, если username используется не просто как отображаемое имя, а для поиска, аутентификации или загрузки профиля).varchar(n) позволяет предотвратить ситуацию, когда приложение пытается сохранить значение, которое невозможно проиндексировать.
💡 Java: sealed types позволяют закрыть граф наследования с помощью permits.
Это даёт полный контроль над тем, какие классы или интерфейсы могут наследоваться от базового типа.
✅ Наследоваться от sealed-класса или интерфейса могут только типы, перечисленные в permits.
✅ Каждый разрешённый подтип должен быть объявлен как final, sealed или non-sealed.
При этом non-sealed — это своего рода «точка выхода»: начиная с такого класса, ограничения снимаются, и наследование снова становится открытым для любых потомков.
#JavaDev
👉 Java Portal
🔍 ТОП-5 ошибок на алгоритмической сессии
Привет, на связи Таня Коровкина из ШОРТКАТ. Ментор по алгоритмам и backend-разработчик
Каждый месяц тысячи разработчиков совершают одни и те же ошибки на алгоритмических интервью 🚩
И продолжают готовиться... не к тому.
Уже сегодня в 19:00 (МСК) проведу вебинар и покажу, что на самом деле оценивает интервьюер и какие ошибки чаще всего приводят к отказу
• дам практические советы, которые можно использовать уже на следующем собеседовании
• расскажу про специфику российского BigTech
🤘 Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы.
Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_sh_bot
Реклама.
О рекламодателе.
Зачем нужен обратный прокси (Reverse Proxy)?
У вас есть API на Node.js.
Поначалу пользователи отправляют запросы напрямую в приложение, и всё работает отлично.
Но по мере роста проекта появляются новые задачи:
- использовать HTTPS;
- раздавать статические файлы;
- применять ограничение частоты запросов (Rate Limiting);
- масштабировать приложение.
Часть этих задач можно решить прямо в API. Но проблема в том, что тогда ему приходится выполнять две разные роли:
реализовывать бизнес-логику (пользователи, платежи, заказы и т. д.);
решать инфраструктурные задачи (HTTPS, раздача статики, Rate Limiting и т. д.).
По мере появления новых инфраструктурных задач становится логично отделить их от бизнес-логики.
Для этого между интернетом и вашим API добавляют дополнительный слой.
Этот слой называется обратным прокси (Reverse Proxy).
Он принимает входящие запросы и решает, что с ними делать: обработать их самостоятельно или перенаправить в API.
Интернет → Reverse Proxy → Ваш API
Одним из самых популярных решений для реализации обратного прокси является NGINX.
Главное преимущество такого подхода в том, что API может полностью сосредоточиться на бизнес-логике, а обратный прокси берёт на себя управление входящим трафиком до того, как он попадёт в приложение.
Недостаток заключается в том, что в архитектуре появляется ещё один компонент, который необходимо настраивать и поддерживать.
Однако по мере роста приложения такое разделение ответственности обычно значительно упрощает масштабирование и сопровождение системы.
👉 Java Portal
Серия о проектировании систем : Кэш
Кэш — это временное хранилище, в котором в памяти сохраняются результаты ресурсоёмких запросов или часто используемые данные, чтобы последующие обращения обрабатывались быстрее.
При каждой загрузке страницы выполняется один или несколько запросов к базе данных. Многократные обращения к базе могут значительно снижать производительность приложения. Кэш помогает решить эту проблему.
> Уровень кэширования
Отдельный уровень кэширования даёт несколько преимуществ:
- повышает производительность системы;
- снижает нагрузку на базу данных;
- позволяет масштабировать кэш независимо от других компонентов.
Работа происходит следующим образом:
1. Получив запрос, веб-сервер сначала проверяет, есть ли нужный ответ в кэше.
2. Если ответ есть, сервер отправляет его клиенту.
3. Если ответа нет, сервер обращается к базе данных, сохраняет результат в кэше и отправляет его клиенту.
Такая стратегия называется read-through cache — «сквозное чтение через кэш».
Существуют и другие стратегии кэширования. Выбор зависит от типа и объёма данных, а также от характера обращений к ним.
> Когда использовать кэш?
Кэш особенно полезен, когда данные:
- часто читаются;
- редко изменяются.
Важные данные должны храниться в постоянном хранилище, поскольку кэш обычно находится в оперативной памяти и не предназначен для долговременного хранения.
> Политика истечения срока действия
Рекомендуется задавать срок жизни кэшированных данных.
Без такой политики данные могут оставаться в памяти неограниченно долго.
Слишком короткий срок жизни приведёт к частым обращениям к базе данных, а слишком длинный — к тому, что данные в кэше устареют.
> Согласованность данных
Необходимо поддерживать синхронизацию между основным хранилищем и кэшем.
Несогласованность может возникнуть, если изменения в базе данных и кэше выполняются не в рамках одной транзакции.
> Предотвращение сбоев
Один сервер кэша является единой точкой отказа, или SPOF — Single Point of Failure.
Поэтому для повышения отказоустойчивости рекомендуется использовать несколько серверов кэша.
> Политика вытеснения
Когда кэш заполняется, добавление новых элементов может приводить к удалению уже существующих.
Этот процесс называется вытеснением из кэша.
Самая популярная политика вытеснения — LRU, Least Recently Used, то есть удаление данных, которые не использовались дольше всего.
👉 Java Portal
💡 Используйте Optional.orElseThrow(), когда отсутствие значения — это ошибка.
✅ orElse(null) → NPE возникает позже, далеко от места поиска значения
✅ orElseThrow() останавливает выполнение в месте возникновения проблемы и выбрасывает понятное исключение
✅ Передавайте Supplier, чтобы в сообщении было указано, какое именно значение отсутствует
#Java #Optional
👉 Java Portal
⚡️💬 Оригинальный Claude API от $0.40 за 1M токенов
Без VPN, дорогих подписок и подмены модели под капотом.
ClaudeHub — для тех, кто использует ИИ в коде, учёбе, работе, ботах и своих проектах.
выбираете Claude — получаете Claude
Платите только за фактическое использование токенов и быстро начинаете через Telegram-бота.
Подходит для Cursor, Claude Code, Cline, Roo, Continue и любых проектов через API.
🆓 Первые 100 пользователей получают 50₽ на баланс по промокоду: FIRST100
✨ Быстрый старт: @claudehub_bot
🔗 Регистрация: app.claudehub.fun/register
💬 Поддержка: t.me/claudehub_support
💡 Java I/O: используйте Files.copy(), чтобы скопировать файл одной строкой.
✅ Отлично подходит для резервных копий: data.csv → data.csv.bak
✅ Используйте REPLACE_EXISTING, если целевой файл уже может существовать
✅ Работает с Path, поэтому код переносим между разными ОС
#Java #Files
👉 Java Portal
Системный дизайн: База данных
По мере роста числа пользователей одного сервера, на котором размещены веб-уровень и уровень данных, становится недостаточно. Поэтому нам потребуется несколько серверов:
- один для обработки веб- и мобильного трафика — веб-уровень (web tier);
- другой для базы данных — уровень данных (data tier).
Разделение серверов, обрабатывающих веб- и мобильный трафик, и серверов базы данных позволяет масштабировать эти уровни независимо друг от друга.
Какую базу данных использовать?
Можно выбрать между традиционной реляционной базой данных — RDBMS, или SQL-базой данных — и нереляционной базой данных — NoSQL.
Реляционные базы данных представляют и хранят данные в виде таблиц и строк. С помощью SQL можно выполнять операции JOIN между различными таблицами базы данных.
Нереляционная база данных может быть подходящим выбором, если:
- приложению требуется сверхнизкая задержка;
- данные неструктурированы или не имеют связей;
- требуется только сериализация и десериализация данных — JSON, YAML и т. д.;
- необходимо хранить огромные объёмы данных.
👉 Java Portal
Новый сервис, для конверта документов в Markdown: https://docs.context.dev/api-reference/utility/parse
Достаточно сделать один API-запрос: отправить содержимое файла и получить на выходе Markdown с сохранённой структурой, ссылками и порядком текста.
Сервис поддерживает PDF, Word, Excel, PowerPoint, HTML, CSV, изображения, исходный код и многие другие форматы. Если документ представляет собой скан или фотографию, встроенный OCR автоматически распознает текст.
👉 Java Portal
Rate Limiting ≠ Throttling ≠ Backpressure
Эти три термина часто используют как взаимозаменяемые…
Но на самом деле они решают совершенно разные задачи масштабирования.
Вот самый простой способ их запомнить:
- Rate Limiting → ограничивает количество запросов, которые клиент может отправить.
- Throttling → ограничивает скорость обработки запросов системой, когда она находится под высокой нагрузкой.
- Backpressure → позволяет медленному потребителю сигнализировать быстрому производителю, чтобы тот снизил скорость и не перегружал систему.
Простая шпаргалка
- Rate Limiting = ограничение количества запросов.
- Throttling = замедление обработки.
- Backpressure = управление потоком данных.
Где используется каждый из подходов?
Rate Limiting
Используется в:
- API Gateway
- Публичных API
- Эндпоинтах авторизации
- Защите от злоупотреблений и DDoS-атак
Типичный ответ сервера:
HTTP/1.1 429 Too Many Requests
PostgreSQL 19 представляет запросы в графовом стиле.
Вместо того чтобы вручную связывать таблицу за таблицей через JOIN
, теперь можно описать путь по данным:
клиент → купил → товар ← купил ← похожий клиент → подписан на → бренд
Такой подход полезен для:
• рекомендательных систем;
• управления доступом;
• обнаружения мошенничества;
• графов знаний (Knowledge Graphs);
• предоставления контекста для AI.
👉 Java Portal
FastAPI с трёхуровневой архитектурой в стиле Java: слои controller, service, crud, schema и model, организованные по аналогии с паттернами Spring Boot. Включает поддержку SQLAlchemy 2.0, авторизации на базе Casbin и Docker.
https://github.com/fastapi-practices/fastapi-best-architecture
👉 Java Portal
Java: Используйте Deque вместо Stack для реализации стека (LIFO — last in, first out, «последним пришёл — первым вышел»).
✅ Stack — это устаревший класс. Он наследуется от Vector и синхронизирует каждую операцию.
✅ Deque поддерживает те же методы: push, pop и peek.
✅ ArrayDeque работает быстрее, чем Stack.
#JavaDev
👉 Java Portal
Массивы в Java
Представьте, что вам нужно хранить оценки 100 студентов.
Неужели вы будете создавать 100 отдельных переменных?
int mark1;
int mark2;
int mark3;
...
int[] scores = {10, 20, 30, 40, 50};Индекс : 0 1 2 3 4
Значение:10 20 30 40 50
int[] numbers;
numbers = new int[5];
int[] numbers = new int[5];
int[] numbers = {10, 20, 30, 40, 50};System.out.println(numbers[2]); // 30
numbers[1] = 25;
numbers.length
for (int i = 0; i < numbers.length; i++) {
System.out.println(numbers[i]);
}int[] arr = new int[3];
0 0 0
int[] arr = {10, 20, 30};
System.out.println(arr[3]);0, 1, 2
💡 Switch-выражения в Java: больше не нужно писать break, а компилятор сам следит за тем, чтобы вы не забыли обработать ни один случай.
✅ По одной строке на каждый case, выражение возвращает значение, break больше не нужен.
✅ Добавили новую константу в enum, но не добавили соответствующий case? Получите ошибку компиляции, а не тихий баг, который проявится только во время выполнения.
👉 Java Portal
Spring Boot: Вы можете реализовать оптимистическую блокировку с помощью аннотации @Version.
✅ Идеально подходит, когда:
операции чтения выполняются часто;
операции записи происходят сравнительно редко;
конфликты возникают редко.
❌ Не подходит, когда:
конфликты происходят часто;
требуется строгая последовательная обработка (strict serialization).
#SpringBoot #JavaDev
👉 Java Portal
НОВИНКА: Устойчивые функции (Durable Functions) в PostgreSQL 🤯
pg_durable — это расширение PostgreSQL. Состояние рабочего процесса, очередь, повторные попытки и восстановление хранятся в Postgres, и оно использует устойчивость Postgres / высокую доступность / резервное копирование / восстановление.
https://techcommunity.microsoft.com/blog/adforpostgresql/introducing-durable-functions-in-postgresql/4526821
👉 Java Portal
Основы системного дизайна
Теорема CAP: почему распределённые системы не могут иметь всё сразу
Представьте, что ваше приложение работает на нескольких серверах в разных городах.
Внезапно...
Сетевое соединение между серверами прерывается.
Теперь у системы есть выбор:
Продолжать принимать запросы?
Или отклонять запросы, пока всё не синхронизируется?
Именно эту проблему решает теорема CAP.
Что такое теорема CAP?
CAP означает:
C — Consistency (Согласованность)
Каждый пользователь видит одни и те же данные, независимо от того, к какому серверу подключился.
Пример: Перевод ₹1000. Каждый сервер сразу показывает обновлённый баланс.
A — Availability (Доступность)
Каждый запрос получает ответ.
Даже если один или несколько серверов недоступны.
Ответ может не содержать самых свежих данных.
P — Partition Tolerance (Устойчивость к разделению)
Система продолжает работать, даже если связь между серверами прервана.
В распределённых системах сетевые сбои неизбежны.
Главное правило. Когда происходит сетевое разделение (partition)...
Можно выбрать только одно из двух:
✔️ Согласованность (Consistency)
ИЛИ
✔️ Доступность (Availability)
Гарантировать оба одновременно нельзя.
Partition Tolerance в распределённых системах не опционален — вы обязаны считать, что это случится.
- CP-системы
Выбирают:
✔️ Согласованность
✔️ Устойчивость к разделению
Пример:
Сервер A ✖️ Сеть ✖️ Сервер B