> 💡 Java: Тестируйте граничные случаи:
✅ Одних тестов счастливого пути недостаточно — они не помогут выявить
✅ Пустые списки и коллекции с одним элементом нередко ведут себя иначе, чем коллекции с «обычными» данными.
✅ Явные тесты для
#Testing
👉 Java Portal
null, пустые коллекции и предельные значения — именно там чаще всего скрываются баги.✅ Одних тестов счастливого пути недостаточно — они не помогут выявить
NullPointerException при отсутствии входных данных.✅ Пустые списки и коллекции с одним элементом нередко ведут себя иначе, чем коллекции с «обычными» данными.
✅ Явные тесты для
null, пустых коллекций, а также минимальных и максимальных значений документируют ожидаемое поведение.#Testing
Please open Telegram to view this post
VIEW IN TELEGRAM
image_2026-07-12_07-37-40.png
1.6 MB
Rate Limiting ≠ Throttling ≠ Backpressure
Эти три термина часто используют как взаимозаменяемые…
Но на самом деле они решают совершенно разные задачи масштабирования.
Вот самый простой способ их запомнить:
- Rate Limiting → ограничивает количество запросов, которые клиент может отправить.
- Throttling → ограничивает скорость обработки запросов системой, когда она находится под высокой нагрузкой.
- Backpressure → позволяет медленному потребителю сигнализировать быстрому производителю, чтобы тот снизил скорость и не перегружал систему.
Простая шпаргалка
- Rate Limiting = ограничение количества запросов.
- Throttling = замедление обработки.
- Backpressure = управление потоком данных.
Где используется каждый из подходов?
Rate Limiting
Используется в:
- API Gateway
- Публичных API
- Эндпоинтах авторизации
- Защите от злоупотреблений и DDoS-атак
Типичный ответ сервера:
Throttling
Используется в:
- Фоновых задачах
- Сервисах с высокой нагрузкой на базу данных
- CPU-интенсивных операциях
- Защите зависимых сервисов во время всплесков трафика
Backpressure
Используется в:
- Kafka-консьюмерах
- Reactive Streams
- Событийно-ориентированных архитектурах
- Стриминговых конвейерах обработки данных
Главная задача — предотвратить переполнение очередей, когда производитель данных работает быстрее, чем потребитель успевает их обрабатывать.
Пример из реальной жизни
Представьте платформу по продаже билетов на концерт во время старта продаж.
Rate Limiting
Каждый пользователь может отправить не более 100 запросов в минуту.
Throttling
Если база данных перегружена, сервис бронирования намеренно снижает скорость обработки запросов до безопасного уровня.
Backpressure
Если сервис уведомлений начинает отставать, поток событий заставляет производителей замедлиться вместо того, чтобы завалить очереди миллионами сообщений.
Самое распространённое заблуждение
- Rate Limiting защищает API от слишком активных клиентов.
- Throttling защищает сам сервис от перегрузки.
- Backpressure защищает потребителей данных от слишком быстрых производителей.
Это не взаимоисключающие механизмы — они часто используются совместно.
Фраза, которую стоит запомнить
- Rate Limiting — *слишком много запросов.*
- Throttling — *обрабатывай медленнее.*
- Backpressure — *я не успеваю, притормози.*
Эти три концепции лежат в основе построения масштабируемых систем, таких как Netflix, Uber, Amazon и событийно-ориентированных архитектур на базе Kafka.
Сохраните эту шпаргалку — она пригодится каждому backend-разработчику и всем, кто изучает проектирование высоконагруженных систем.
👉 Java Portal
Эти три термина часто используют как взаимозаменяемые…
Но на самом деле они решают совершенно разные задачи масштабирования.
Вот самый простой способ их запомнить:
- Rate Limiting → ограничивает количество запросов, которые клиент может отправить.
- Throttling → ограничивает скорость обработки запросов системой, когда она находится под высокой нагрузкой.
- Backpressure → позволяет медленному потребителю сигнализировать быстрому производителю, чтобы тот снизил скорость и не перегружал систему.
Простая шпаргалка
- Rate Limiting = ограничение количества запросов.
- Throttling = замедление обработки.
- Backpressure = управление потоком данных.
Где используется каждый из подходов?
Rate Limiting
Используется в:
- API Gateway
- Публичных API
- Эндпоинтах авторизации
- Защите от злоупотреблений и DDoS-атак
Типичный ответ сервера:
HTTP/1.1 429 Too Many Requests
Throttling
Используется в:
- Фоновых задачах
- Сервисах с высокой нагрузкой на базу данных
- CPU-интенсивных операциях
- Защите зависимых сервисов во время всплесков трафика
Backpressure
Используется в:
- Kafka-консьюмерах
- Reactive Streams
- Событийно-ориентированных архитектурах
- Стриминговых конвейерах обработки данных
Главная задача — предотвратить переполнение очередей, когда производитель данных работает быстрее, чем потребитель успевает их обрабатывать.
Пример из реальной жизни
Представьте платформу по продаже билетов на концерт во время старта продаж.
Rate Limiting
Каждый пользователь может отправить не более 100 запросов в минуту.
Throttling
Если база данных перегружена, сервис бронирования намеренно снижает скорость обработки запросов до безопасного уровня.
Backpressure
Если сервис уведомлений начинает отставать, поток событий заставляет производителей замедлиться вместо того, чтобы завалить очереди миллионами сообщений.
Самое распространённое заблуждение
- Rate Limiting защищает API от слишком активных клиентов.
- Throttling защищает сам сервис от перегрузки.
- Backpressure защищает потребителей данных от слишком быстрых производителей.
Это не взаимоисключающие механизмы — они часто используются совместно.
Фраза, которую стоит запомнить
- Rate Limiting — *слишком много запросов.*
- Throttling — *обрабатывай медленнее.*
- Backpressure — *я не успеваю, притормози.*
Эти три концепции лежат в основе построения масштабируемых систем, таких как Netflix, Uber, Amazon и событийно-ориентированных архитектур на базе Kafka.
Сохраните эту шпаргалку — она пригодится каждому backend-разработчику и всем, кто изучает проектирование высоконагруженных систем.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4
Системный дизайн: Архитектура с одним сервером
Проектирование системы, способной обслуживать миллионы пользователей, — сложная задача. Это долгий путь, требующий постоянной доработки и непрерывного улучшения.
Обычно всё начинается с простого варианта: все компоненты работают на одном сервере.
Посмотрим, как проходит запрос:
> Пользователь обращается к
> DNS преобразует доменное имя в IP-адрес
> Запрос поступает на единственный веб-сервер.
> Сервер выполняет всё самостоятельно:
обрабатывает API-запрос;
выполняет бизнес-логику;
обращается к базе данных.
> Сервер отправляет пользователю HTML-страницу или JSON-ответ для дальнейшего отображения.
👉 Java Portal
Проектирование системы, способной обслуживать миллионы пользователей, — сложная задача. Это долгий путь, требующий постоянной доработки и непрерывного улучшения.
Обычно всё начинается с простого варианта: все компоненты работают на одном сервере.
Посмотрим, как проходит запрос:
> Пользователь обращается к
api.mysite.com через веб-приложение или мобильное приложение.> DNS преобразует доменное имя в IP-адрес
27.220.30.232.> Запрос поступает на единственный веб-сервер.
> Сервер выполняет всё самостоятельно:
обрабатывает API-запрос;
выполняет бизнес-логику;
обращается к базе данных.
> Сервер отправляет пользователю HTML-страницу или JSON-ответ для дальнейшего отображения.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤2
Новый сервис, для конверта документов в Markdown: https://docs.context.dev/api-reference/utility/parse
Достаточно сделать один API-запрос: отправить содержимое файла и получить на выходе Markdown с сохранённой структурой, ссылками и порядком текста.
Сервис поддерживает PDF, Word, Excel, PowerPoint, HTML, CSV, изображения, исходный код и многие другие форматы. Если документ представляет собой скан или фотографию, встроенный OCR автоматически распознает текст.
👉 Java Portal
Достаточно сделать один API-запрос: отправить содержимое файла и получить на выходе Markdown с сохранённой структурой, ссылками и порядком текста.
Сервис поддерживает PDF, Word, Excel, PowerPoint, HTML, CSV, изображения, исходный код и многие другие форматы. Если документ представляет собой скан или фотографию, встроенный OCR автоматически распознает текст.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4
Databasement — это инструмент для управления резервными копиями баз данных через self-hosted веб-интерфейс.
👉 Java Portal
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - David-Crty/databasement: Self-hosted database backup manager with a web UI. Schedule, backup, and restore MySQL, PostgreSQL…
Self-hosted database backup manager with a web UI. Schedule, backup, and restore MySQL, PostgreSQL, MariaDB, Microsoft SQL Server, MongoDB, SQLite & Redis to S3, SFTP, or local storage. SSH...
Системный дизайн: База данных
По мере роста числа пользователей одного сервера, на котором размещены веб-уровень и уровень данных, становится недостаточно. Поэтому нам потребуется несколько серверов:
- один для обработки веб- и мобильного трафика — веб-уровень (web tier);
- другой для базы данных — уровень данных (data tier).
Разделение серверов, обрабатывающих веб- и мобильный трафик, и серверов базы данных позволяет масштабировать эти уровни независимо друг от друга.
Какую базу данных использовать?
Можно выбрать между традиционной реляционной базой данных — RDBMS, или SQL-базой данных — и нереляционной базой данных — NoSQL.
Реляционные базы данных представляют и хранят данные в виде таблиц и строк. С помощью SQL можно выполнять операции JOIN между различными таблицами базы данных.
Нереляционная база данных может быть подходящим выбором, если:
- приложению требуется сверхнизкая задержка;
- данные неструктурированы или не имеют связей;
- требуется только сериализация и десериализация данных — JSON, YAML и т. д.;
- необходимо хранить огромные объёмы данных.
👉 Java Portal
По мере роста числа пользователей одного сервера, на котором размещены веб-уровень и уровень данных, становится недостаточно. Поэтому нам потребуется несколько серверов:
- один для обработки веб- и мобильного трафика — веб-уровень (web tier);
- другой для базы данных — уровень данных (data tier).
Разделение серверов, обрабатывающих веб- и мобильный трафик, и серверов базы данных позволяет масштабировать эти уровни независимо друг от друга.
Какую базу данных использовать?
Можно выбрать между традиционной реляционной базой данных — RDBMS, или SQL-базой данных — и нереляционной базой данных — NoSQL.
Реляционные базы данных представляют и хранят данные в виде таблиц и строк. С помощью SQL можно выполнять операции JOIN между различными таблицами базы данных.
Нереляционная база данных может быть подходящим выбором, если:
- приложению требуется сверхнизкая задержка;
- данные неструктурированы или не имеют связей;
- требуется только сериализация и десериализация данных — JSON, YAML и т. д.;
- необходимо хранить огромные объёмы данных.
Please open Telegram to view this post
VIEW IN TELEGRAM
Java Streams:
✅ Полезно при работе со
✅
✅ Отлично подходит для выборки данных или получения первых N значений
#Java #Streams
👉 Java Portal
limit(n) превращает бесконечный поток в конечный.✅ Полезно при работе со
Stream.iterate() / generate() — они могут создавать бесконечные потоки✅
limit(5) означает: «взять первые 5 элементов и остановиться»✅ Отлично подходит для выборки данных или получения первых N значений
#Java #Streams
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7
💡 Java I/O: используйте
✅ Отлично подходит для резервных копий:
✅ Используйте
✅ Работает с
#Java #Files
👉 Java Portal
Files.copy(), чтобы скопировать файл одной строкой.✅ Отлично подходит для резервных копий:
data.csv → data.csv.bak✅ Используйте
REPLACE_EXISTING, если целевой файл уже может существовать✅ Работает с
Path, поэтому код переносим между разными ОС#Java #Files
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Сис. дизайн: Балансировщик нагрузки
Балансировщик нагрузки равномерно распределяет входящий трафик между веб-серверами, объединёнными в балансируемую группу.
- Пользователь подключается напрямую к публичному IP-адресу балансировщика нагрузки. При такой схеме клиенты больше не могут обращаться к веб-серверам напрямую.
- Это повышает безопасность: для взаимодействия между серверами используются приватные IP-адреса, недоступные из интернета.
- Балансировщик нагрузки взаимодействует с веб-серверами через приватные IP-адреса.
Добавив второй веб-сервер, мы устранили проблему отсутствия отказоустойчивости и повысили доступность веб-уровня.
- Если сервер 1 выйдет из строя, весь трафик будет перенаправлен на сервер 2. Это не позволит сайту стать недоступным.
- Если трафик сайта резко вырастет и двух серверов окажется недостаточно, балансировщик нагрузки позволит корректно решить эту проблему. В пул можно добавить дополнительные веб-серверы, после чего балансировщик автоматически начнёт направлять запросы и на них.
Вертикальное и горизонтальное масштабирование
Вертикальное масштабирование, также называемое scale up, — это процесс увеличения мощности серверов: добавления CPU, оперативной памяти и других ресурсов.
Горизонтальное масштабирование, также называемое scale out, позволяет масштабировать систему за счёт добавления новых серверов в пул ресурсов.
При низкой нагрузке вертикальное масштабирование может быть хорошим вариантом, а его главное преимущество — простота.
Ограничения вертикального масштабирования
- Невозможно бесконечно добавлять CPU и память одному серверу.
- Отсутствует отказоустойчивость. Если сервер выходит из строя, сайт или приложение полностью перестаёт работать.
Для крупномасштабных приложений горизонтальное масштабирование обычно предпочтительнее из-за ограничений вертикального масштабирования.
Если множество пользователей одновременно обращаются к веб-серверу и нагрузка достигает его предела, пользователи сталкиваются с увеличением времени ответа или вообще не получают ответ.
Эта проблема решается с помощью горизонтального масштабирования и балансировщика нагрузки.
👉 Java Portal
Балансировщик нагрузки равномерно распределяет входящий трафик между веб-серверами, объединёнными в балансируемую группу.
- Пользователь подключается напрямую к публичному IP-адресу балансировщика нагрузки. При такой схеме клиенты больше не могут обращаться к веб-серверам напрямую.
- Это повышает безопасность: для взаимодействия между серверами используются приватные IP-адреса, недоступные из интернета.
- Балансировщик нагрузки взаимодействует с веб-серверами через приватные IP-адреса.
Добавив второй веб-сервер, мы устранили проблему отсутствия отказоустойчивости и повысили доступность веб-уровня.
- Если сервер 1 выйдет из строя, весь трафик будет перенаправлен на сервер 2. Это не позволит сайту стать недоступным.
- Если трафик сайта резко вырастет и двух серверов окажется недостаточно, балансировщик нагрузки позволит корректно решить эту проблему. В пул можно добавить дополнительные веб-серверы, после чего балансировщик автоматически начнёт направлять запросы и на них.
Вертикальное и горизонтальное масштабирование
Вертикальное масштабирование, также называемое scale up, — это процесс увеличения мощности серверов: добавления CPU, оперативной памяти и других ресурсов.
Горизонтальное масштабирование, также называемое scale out, позволяет масштабировать систему за счёт добавления новых серверов в пул ресурсов.
При низкой нагрузке вертикальное масштабирование может быть хорошим вариантом, а его главное преимущество — простота.
Ограничения вертикального масштабирования
- Невозможно бесконечно добавлять CPU и память одному серверу.
- Отсутствует отказоустойчивость. Если сервер выходит из строя, сайт или приложение полностью перестаёт работать.
Для крупномасштабных приложений горизонтальное масштабирование обычно предпочтительнее из-за ограничений вертикального масштабирования.
Если множество пользователей одновременно обращаются к веб-серверу и нагрузка достигает его предела, пользователи сталкиваются с увеличением времени ответа или вообще не получают ответ.
Эта проблема решается с помощью горизонтального масштабирования и балансировщика нагрузки.
Please open Telegram to view this post
VIEW IN TELEGRAM
Без VPN, дорогих подписок и подмены модели под капотом.
ClaudeHub — для тех, кто использует ИИ в коде, учёбе, работе, ботах и своих проектах.
выбираете Claude — получаете Claude
Платите только за фактическое использование токенов и быстро начинаете через Telegram-бота.
Подходит для Cursor, Claude Code, Cline, Roo, Continue и любых проектов через API.
Please open Telegram to view this post
VIEW IN TELEGRAM
💊4