How Stripe Processed $1 Trillion in Payments with Zero Downtime
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
————————————— Optimistic Concurrency Control: Alice and Bob Couldn’t Sit Together
Проблема распределенных вычислений — гонки связанные с изменением данных. Для чего используют локи. Если говорим о гонках на уровне базы, то кажется, что можно не запариваться, так как в 80% случаев код скорее всего будет работать. Но в цельности, знать о локах и уметь использовать подход придется. А с пониманием работы поможет статья, где автор рассказывает об оптимистичной блокировке в контексте постгреса.
Статья крутиться вокруг одного примера: Алиса и Боб хотят купить билеты в кино. При этом, сделать это так, что бы сидеть рядом. Дальше Боб делает транзакцию, в которой проверяет наличие двух мест рядом и ждет, пока Алиса забронирует место, чтобы самому забронировать место рядом (транзакция все еще висит). Но в этот момент появляется Mallory, которая также хочет забронировать место (но не может из-за транзакции Боба). Дальше Боб с Алисой делают UPDATE для бронирования места и коммитят транзакцию. И по итогу, Mallory окажется без билета, а Боб с Алисой пойдут в кино. А во второй части показано как будет работать optimistic lock для aws Aurora DSQL.
#sql #optimistic_lock
—————————————
Simple tips for managing any project.
Статья от Simon Wardley (это тот, кто придумал карты вордли), в которой рассказывает о базовых принципах в управлении проектами, который использует 15 лет. Для этого он рассказывает о проекте, в котором изначально выбрали не корректно элементы системы из-за чего начались проблемы. Дальше описываются шесть вопросов, которые помогут решить проблемы с проектами. Шаги похожи на то, что предлагает стратегический DDD и если шаги сгруппировать получите следующие направления:
- понимание пользователей и их нужд;
- определение capabilities, которые закрывают нужды пользователей;
- понимание развития компонентов, которые связаны с capabilities;
- менеджмент компонентов.
Дальше автор описывает проблемы, из-за которых происходят провалы. Тут найдете: проблемы с коммуникациями, mismatched expectations стейкхолдеров, проблемы с ясностью целей, проблемы с remote teams, культурными особенностями и проблемы с границами элементов.
В конце дописаны ответы на некоторые вопросы. Важно отметить, что примеры в тексте показаны только через карты, но заменив карты на поддомены и контексты из DDD, смысл не поменяется.
#management #product
—————————————
How Stripe Processed $1 Trillion in Payments with Zero Downtime
Очередная статья из серии «как в компании X решили проблему Y». На этот раз это страйп, который обработал триллион долларов платежей за год без простоев. Изначально страйп использовал mongoDB, сначала казалось что база проще реляционной в работе. Но из-за нагрузки и количества данных оказалось, что вариант так себе. При этом шардирование монги не помогло (в тексте найдете кусок о том, как шардирование работает). В результате появилась DocDB, основанная на монге, где за хранение и извлечение отвечает монга, а за шардирование и миграции отвечает DocDB.
Дальше описывается, как работает Data Movement Platform — штука, которая помогает перемещать данные между шардами, особенно когда размер шарда выходит за допустимые пределы и нужно добавлять новый. Проблема тут не только в том, чтобы переместить информацию, но и сделать так, что бы связанные данные также переместились в нужный шард. Дальше описан полный алгоритм работы шардирования. А в конце найдете ссылку на оригинальную статью
#how_it_works #sharding
Stripe’s hand-crafted system that guarantees their data never gets lost