Найти в Дзене
🔹 Согласованность данных: eventual vs strong
🔹 Что такое eventual consistency и когда её можно допустить вместо strong consistency? 🔸 Смысл: при распределённой системе разные узлы могут отдавать разные ответы из‑за задержек или сетевых сбоев — eventual consistency решает проблему доступности и масштабирования, позволяя системе продолжать работу, пока данные синхронизируются. 🔸 eventual consistency — обновления распространяются асинхронно: читатель может увидеть старое значение некоторое время; возможен conflict (конфликт) при параллельных записях и нужен механизм разрешения (merge, last‑write‑wins)...
4 часа назад
🔹 Индексы в PostgreSQL: какие выбрать и почему
🔹 Какие типы индексов в PostgreSQL и когда их применять? 🔸 Индекс решает проблему медленных full table scan: он ускоряет поиск, но увеличивает запись и занимает место. Выбираем тип по характеру запросов и по операторам, которые используем. 🔸 B-tree — дефолтный индекс. Отлично для равенств, диапазонов, ORDER BY и UNIQUE. Используйте для PK, FK и числовых/строковых колонок с сортировкой. 🔸 Hash — индекс только для равенств. Подходит, когда много точечных = запросов и B-tree не даёт нужной производительности; обычно реже применяется из‑за ограниченной поддержки операторов...
1 день назад
🔹 Асинхронность vs конкурентность: python-практика
🔹 Чем отличаются concurrency и parallelism — и как asyncio + threadpool играют вместе? 🔸 concurrency решает проблему простаивания: позволяет управлять множеством задач одновременно, чтобы не блокировать поток при ожидании I/O (input/output). 🔸 parallelism — реальное параллельное выполнение на разных ядрах CPU (central processing unit); нужен для ускорения CPU-bound операций, иначе многозадачность не даст прироста. 🔸 Практика: для I/O-bound используйте asyncio; для блокирующих или CPU-bound функций — отправляйте их в threadpool (ThreadPoolExecutor) или в process pool...
2 дня назад
🔹 Event Sourcing: восстановление состояния через журнал событий
🔹 Как восстановить состояние системы из событий? 🔸 Сохраняем изменения как события, а не перезаписываем состояние. Это решает проблему потери истории и даёт источник правды для recovery: event store — append-only immutable log, где каждое событие фиксирует изменение. 🔸 Во время восстановления читаем event store и реиграем события (реиграть события) в приложении: последовательное применение событий строит текущее состояние. Пример реигровки: state = State() for e in event_store...
3 дня назад
🔹 Результаты недели: идемпотентность, prompt injection, SRE и OKR
🔹 Что из этого нужно прямо сейчас? 🔸 идемпотентность нужна, чтобы повторные запросы не создавали дубли и не ломали данные: при сбоях клиент может ретраить — система должна вернуть тот же результат или отклонить повтор. Практика: хранить request_id и проверять его. 🔸 prompt injection — это попытка через ввод изменить поведение системы; проблема в доверии к входным данным. Защита: фильтры, строгие шаблоны, контекстная валидация и тестовые запросы. 🔸 SRE (Site Reliability Engineering) vs DevOps...
3 дня назад
Если нравится — подпишитесь
Так вы не пропустите новые публикации этого канала