В 2020м году сервис Notion получил увеличение нагрузки на их монолитную базу и стало понятно, что использование продукта превышает возможности, которые может позволить себе Postgres в виде базы без шардов.
Сегодня я принес вам статью, в которой инженеры Notion делятся своим опытом по шардированию базы Postgres.
Статья про интересный подход к написанию чистого кода.
Не только с точки зрения архитектурных подходов, но и со стороны нашей долгосрочной и краткосрочной памяти, а также того как она работает во время чтения кода.
Проблемы микросервисов:
Сегодня очень полезная информация для прохождения секции system design: пример пошагового проектирования системы на подобии Google Places - сервисов, которые основаны на поиске ближайших к вам мест по критериям - рестораны, гостиницы, заправки и т.д. Смотреть видео
Один из самых частых этапов при подготовке к собеседованиям - это решение алгоритмических задач на Leetcode.
И помимо пользы от решения самих задач, платформа вводит некий соревновательный момент, отображая процент пользователей, которые в принципе решили эти задачи.
Сегодня я делюсь с вами интересным видео, в котором автор взял TOP-3 задачи, по которым меньше всего процент успешных решений и пытается их решить, попутно делясь алгоритмами и подходами к решению.
Статья Netflix про их собственную реализацию очередей с приоритетом, которая имеет высокую пропускную способность при минимальных задержках и покрывает все потребности их платформы.
Статья подробно рассказывает про ключевые концепции системы, охватывает историю её создания и развития, а также архитектуру на которой она построена.
При разработке распределенного приложения, рано или поздно вы столкнетесь с проблемой, когда разным частям вашей системе потребуется согласованность данных друг с другом.
Но как быть, если у вас нет архитектуры распределенных транзакций?
Ответить на этот вопрос на примере одного из кейсов, где возникает подобная проблема, попробует автор видео.
Оптимизация объявления структур в Golang с точки зрения потребляемой памяти и процессорного времени.
Продолжаем тему решения различных проблем микросервисной архитектуры после перехода с монолита.
Сегодня речь пойдет про авторизацию и best practice по ее реализации в микросервисной архитектуре.
Еще одна проблема в микросервисной архитектуре после перехода с монолита - это транзакции.
Теперь, вместо единой точки исполнения бизнес-логики, у вас несколько коммуницирующих между собой сервисов, каждый их которых исполняют свою роль в рамках одного сценария. И в любом из них может что-то пойти не так - от недоступности сервиса, до реальной ошибки бизнес-логики.
Для микросервисной архитектуры есть подход распределенных транзакций, но он не лишен изъянов.
Сегодняшняя статья расскажет в том числе про такие изъяны, а также предложит новый вариант решения проблемы транзакций в распределенной системе.
Неделю назад я делился с вами статьей про реализацию событий-ориентированной архитектуры, а сегодня хочу поделиться статьей про пятерку подводных камней данного подхода и советы по их избеганию или решению.
Одна из основных проблем микросервисов - это проблема их коммуникации.
Если вы выберете неверную стратегию, то велика вероятность вместо микросервисной архитектуры получить распределённый монолит.
В сегодняшней статье приводятся основные виды коммуникации между микросервисами, их плюсы и минусы.