При разработке распределенного приложения, рано или поздно вы столкнетесь с проблемой, когда разным частям вашей системе потребуется согласованность данных друг с другом.

Но как быть, если у вас нет архитектуры распределенных транзакций?

Ответить на этот вопрос на примере одного из кейсов, где возникает подобная проблема, попробует автор видео

https://www.youtube.com/watch?v=Trl4--FO7Yo

#microservices

Статья Netflix про их собственную реализацию очередей с приоритетом, которая имеет высокую пропускную способность при минимальных задержках и покрывает все потребности их платформы.

Статья подробно рассказывает про ключевые концепции системы, охватывает историю её создания и развития, а также архитектуру на которой она построена

https://netflixtechblog.com/timestone-netflixs-high-throughput-low-latency-priority-queueing-system-with-built-in-support-1abf249ba95f

#highload

Один из самых частых этапов при подготовке к собеседованиям - это решение алгоритмических задач на Leetcode.

И помимо пользы от решения самих задач, платформа вводит некий соревновательный момент, отображая процент пользователей, которые в принципе решили эти задачи.

Сегодня я делюсь с вами интересным видео, в котором автор взял TOP-3 задачи, по которым меньше всего процент успешных решений и пытается их решить, плпутно делясь алгоритмами и подходами к решению

https://youtu.be/Ow1D5O05NfM

#leetcode

Привет!

Сегодня очень полезная информация для прохождения секции system design: пример пошагового проектирования системы на подобии Google Places - сервисов, которые основаны на поиске ближайших к вам мест по критериям - рестораны, гостиницы, заправки и т.д.

https://youtu.be/M4lR_Va97cQ

#systemdesign

Проблемы микросервисов

- сетевые издержки на коммуникацию между функциями
- сложности при отладке из-за распределенности системы
- усложнение архитектуры
- одинаковые функции в разных микросервисах

Про решение первых трех есть немало статей, в том числе и в этом канале они были - тут и тут

Сегодня я делюсь статьей с best practices решения проблем дублирования кода - вынесения его в библиотеки и переиспользование в нескольких независмых сервисах.

https://medium.com/duda/shared-libraries-design-and-best-practices-710774ae0bdc

#microservices

Статья про интересный подход к написанию чистого кода.

Не только с точки зрения архитектурных подходов, но и со стороны нашей долгосрочной и краткосрочной памяти, а также того как она работает во время чтения кода.

https://davidamos.dev/the-rule-of-six/

#cleancode

В 2020м году сервис Notion получил увеличение нагрузки на их монолитную базу и стало понятно, что использование продукта превышает возможности, которые может позволить себе Postgres в виде базы без шардов.

Сегодня я принес вам статью, в которой инженеры Notion делятся своим опытом по шардированию базы Postgtres

https://blog.quastor.org/p/notion-sharded-postgres-database-8af4

#postgresql #postgres #database #systemdesign

Пятичасовое видео с примерами решения типовых алгоритмических задач из категории динамического программирования

Автор показывает два подхода к решению одной и той же задачи - при помощи мемоизации и табуляции, а также во всех случаях объясняет сложности по времени и памяти

https://www.youtube.com/watch?v=oBt53YbR9Kk

#leetcode #dp

Для тех кто выдержал пять часов про динамическое программирование - сегодня я принес восемь часов про структуры данных

Видео представляет из себя компиляцию нескольких последовательных уроков, которые охватывают как классические структуры, так и менее популярные - например Union Find

Для каждой структуры данных есть разбор сложности базовых операций, а также ее имплементация.

В целом - даже если вы знаете на зубок все что представлено в уроках - они станут отличным способом упорядочения информации в голове

https://youtu.be/RBSGKlAvoiM

#leetcode #ds

Павел Агалецкий, ведущий инженер в Авито, расскажет, как в компании построили надежную во всех смыслах шину данных для обмена событиями между сервисами на основе Apache Kafka. Как эволюционировала шина, как гарантируется соблюдение контрактов публикуемых событий и какие есть способы переживать даже отказ дата-центра.

https://youtu.be/mx5JzpfwjLo

#kafka #microservices

Читая очередную статью про распределнные системы, наткнулся на интересный факт: New York Times использует Kafka в качестве основной базы данных для всех своих статей. "Всех" означает что каждая статья, каждая ее правка, каждый заголовок с пометкой "молния" - хранится в брокере сообщений и никогда не будет удален. А это более чем 170 лет истории.

Нашел статью, в которой описан сам подход к log-based архитектуре, а также то, как конкретно это реализовано у New York Times.

https://www.confluent.io/blog/publishing-apache-kafka-new-york-times/

#systemdesign #kafka

Пишу юнит-тесты почти 5 лет и основные сражения, которые я видел по их поводу, заключались только в том - писать по TDD или нет.

Но сегодня наткнулся на то, что оказывается есть два способа тестирования - классический из Детройта и мокистский из Лондона.

Основная разница только в том, какая часть является юнитом и какие зависимости нужно заменять заглушками с ожидаемым поведением. В классической школе - юнитом является поведение и заглушками заменяются только те зависимости, которые могут повлиять на другие тесты или являются внешними - БД, файловая система, http-запросы. А при лондонском подходе - почти все зависимости заменяются на заглушки и тестируется только отдельный класс и его методы. Это делает тесты по-настоящему изолированными.

Подробнее про различия в статье

Что касается меня и моего выбора относительно юнит-тестов, то для бизнесового кода я конечно же выберу подход Детройта - нет смысла делать моками абсолютно все зависимости, так как эта изоляция приносит больше вреда чем пользы, напрмиер при рефакторинге - когда поведение у вас не меняется, но при этом тесты падают если вы меняете внешний вызов или исправляете SQL-запрос например.

Однако, совсем сбрасывать со счетов лондонский подход я бы тоже не стал - максимально изолированные тесты могут быть полезны при тестировании чистых функций, например в библиотеках, в которых результат зависит только от входных данных и никак не взаимодействует со внешним миром.

А что насчет вас? Какой подход выберите?

#coding #test

🐘 Погружение в детали работы EXPLAIN в PostgreSQL: как читать планы запросов, когда появляется и как работает каждый из узлов, какую информацию можно получить из атрибутных строк.

Часть 1
Часть 2

#database #postgresql #postgres

🚕 История масштабирования Uber: от MVP на LAMP стеке в 2009м через монолитный Postgres в 2014м и до полноценной микросервисной архитектуры на Go и Java с 2020го

Оригинальная статья

Обсуждение на стриме FaangTalk

#systemdesign #experience

Подборка скрытых, но очень мощных фишек PostgreSQL, которые могут резко упростить SQL и сделать вас сильнее как разработчика: от умных идентификаторов до продвинутой агрегации и чистых JOIN’ов.

Коротко, понятно и сразу применимо.

https://devbackend.ru/posts/2025-11-23-useful-postgres-features

#database #postgresql #postgres

Переход к микросервисам даёт гибкость, но разрушает привычную целостность данных: в разных сервисах — свои БД, и провести единую ACID-транзакцию почти невозможно.

Saga и Two‑Phase Commit (2PC) — два основных подхода.

Детальный разбор и сравнение подходов

#microservices #architecture

По вечерам я сейчас работаю над проектом, нацеленным над easy2run servless приложений.

Serverless продаётся как технология без серверов с автоматическим масштабированием и полной экономичностью.

Но реальность сложнее.

Антон Черноусов в своём докладе на DevOps конференции 2023 года развенчивает основные мифы о serverless и рассказывает, как на самом деле работает эта технология.

Доклад будет полезен всем, кто думает о переходе на serverless или уже использует эту технологию и хочет понять её ограничения и лучшие практики.

Смотреть доклад

#serverless #lambda #archicture

На новой работе, я сделал то, что обычно не принято: превратил микросервисную архитектуру в монолит.

И причин тому несколько:

- команда разработки всего два человека: мы не толкались локтями в одних и тех же файлах и модулях

- каждый микросервис делал одинаковую задачу: забирал данные из ERP (каждый из своей) и отправлял в мастер систему

- 80% кода это копипаст так как нет настроенной системы для работы с приватными библиотеками

- каждый сервис эксплуатировал только 5-10% выделенных ресурсов

Нашел как раз статью на тему того, как микросервисы могут не только усложнить разработку, но и привести к увеличению time-to-market, за счет увеличения времени на тестирование и отладку.

Читать статью

#microservices #architecture

Начало нового года отличное время для подведения итогов года предыдущего.

Tech Talks Weekly опубликовал подборку самых просматриваемых технических докладов года

Rust: экосистема движется к full-stack разработке. Leptos, Dioxus, внедрение в Microsoft и 10 лет Redox OS

Go: Go 1.25, observability с OpenTelemetry, cloud resilience паттерны и масштабирование больших кодовых баз

Python: "Escape from Tutorial Hell", Polars, DuckDB и структурированные RAG паттерны для AI

Смотреть доклады

#go #rust #python