Одна из основных проблем микросервисов - это проблема их коммуникации.

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

В сегодняшней статье приводятся основные виды коммуникации между микросервисами, их плюсы и минусы

https://skolaparthi.com/communication-between-microservices/

#microservices

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

https://medium.com/wix-engineering/event-driven-architecture-5-pitfalls-to-avoid-b3ebf885bdb1

#systemdesign

Еще одна проблема в микросервисной архитектуре после перехода с монолита - это транзакции.

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

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

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

https://krishnakrmahto.com/transactional-messaging-in-microservices

#microservices

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

Сегодня речь пойдет про авторизацию и best practise по ее реализации в микросервисной архитектуре

https://www.osohq.com/post/microservices-authorization-patterns

#microservices

Оптимизация объявления структур в Golang с точки зрения потребляемой памяти и процессорного времени

https://towardsdev.com/golang-writing-memory-efficient-and-cpu-optimized-go-structs-62fcef4dbfd0

#golang

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

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

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

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