Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
You Don’t Need Ordered Events, You Need Smart Events
Сегодня еще одна статья о event-driven коммуникациях. Вместо обсуждения того, как дергать брокер, автор решил сфокусироваться на том, что должно быть в событии и как ордеринг обеспечить за счет данных в событии. Единственное о чем надо знать — текст специфичен для aws стека.
Начинается текст с описания того, что должно по данным лежать в событии. Причем рассуждения касаются мета информации в событии, а не данных «бизнес-логики» (единственное, поспорил бы с автором о
entityID и его формате). Далее затрагивается тема ордеринга, причем автор, вместо перекладывания ответственности на продюсер и брокер, предлагает пойти через версии данных. Пример реализации и отсылки к dynamoDB также присутствуют. К концу автор сравнивает Amazon SNS и EventBridge по ordering, filtering и другим свойствам. Ну и понравилось, что в самом конце указывается, когда о нормальном ордеринге думать придется (если предположили, что в fintech — угадали).Русский перевод
#event_driven
—————————————
The startup's Postgres survival guide
Автор текста выше сразу пишет, что изначальная цель статьи — создание гайда по постгресу, который был бы полезнее официальной документации. В итоге получился набор советов разделенных на три группы:
- советы по чтению, записи и схемам;
- советы вокруг планировщиков, автовакуума и bulk операций;
- остальные советы.
О каждом совете писать смысла не вижу, поэтому в общих словах опишу что ждать от каждой из групп. В случае чтения/записи и схем даются советы о том, как спроектировать схему бд, как индексы помогают (включая составные), ну и упоминается очевидный совет о вызове стороннего кода/системы в транзакции. В случае планировщиков — как относится к планировщику, что делать, когда вместо индекса постгрес идет другим путем, как bulk операции обрабатывать. Последняя группа советов относится к
FOR UPDATE SKIP LOCKED, партицированию и советам по миграции больших таблиц.Если пишите код агентами — в начале текста найдете ссылку на скилы по работе с постгресом.
#psql
—————————————
Introducing Meerkat: an experiment in global consensus
Мне нравится разбираться с алгоритмами консенсуса (правда раз в пару лет), поэтому сегодня тематическая статья. Разработчики из cloudflare сделали meerkat — собственную реализацию consensus service, которая еще разрабатывается. И как написали в статье, сервис публичным не будет в ближайшее время.
Текст начинается с описания проблемы: проблемы вокруг согласования control-plane data на масштабах cloudflare. В компании пробовали raft, но из-за специфики работы лидер нод возникли проблемы, из-за чего было принято решение делать собственное решение на основе QuePaxa алгоритма. Далее описывается что от strong consistency требуется в компании, из-за чего авторы подводят к термину linearizability (свойство упорядочиваемости операций). После рассказывается о fault tolerance. Тут разработчикам важно, чтобы при деградации клиент мог продолжать работу, с чем raft не помогает. Далее рассказывается о meerkat: описывается архитектура, как работает эвент лог и как благодаря логу достигается strong consistency. В конце meerkat сравнивается с raft алгоритмом.
#how_it_works #distributed_systems