Коротко о главном: максимально субъективный взгляд на IT, технологии и архитектуру

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

Welcome в dpr/dev space !

PS: (токсичным) Желающим похоливарить про кафку тут всегда рады.


Полезные теги для поиска

#orchestration
#distributed_transactions
#temporal
#security
#auth
#dotnet
#efcore
#db
#db_design
#dwh
#system_design
#api_design
#infrastructure

Наблюдая извечные холивары о том, что такое МСА, когда нужно применять МСА, чем МСА лучше монолита, становится немного грустно: к сожалению, многие люди тотально не понимают двух вещей
1) довольно большое количество людей было введено в заблуждение относительно многих вещей, касающихся МСА
2) довольно немногие в действительности понимают, когда и зачем нужно декомпозировать монолит на разные деплоймент-юниты (сервисы. в привычной для всех терминологии)

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

Проблема этих утверждений в том, что они имеют место быть только при очень большом количестве «если», которые нужно каждый раз явно озвучивать.
Обычно этого не делают, что порождает многочасовые споры, а сами доводы переводит в разряд «набросов». Кто из нас не слышал фразы по типу «у меня такой же монолит и не болит (так же скейлится, более надежен и тд)

Глядя на все это, давно посещает мысль написать цикл статей на эту тему.
Возможно, начну со скейлинга (или очередного определения мса 🙈)

#temporal
#distributed_transactions
#orchestration

Temporal: Введение. Часть 1

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

Естественно, такие преимущества, как персистентность шагов, восстановление после сбоев (DR), высокая скорость исполнения и прочее — все это присутствует. Почитать можно здесь.

Сам Temporal состоит из нескольких ключевых компонентов:

- Кластер — платформа, которая умеет планировать задачи, выполнять их, регистрировать воркеры и т.д.
- Воркеры — отдельные приложения, которые хостят и запускают реализованные инженерами процессы (в дальнейшем — воркфлоу).

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

Важно понимать следующее: все шаги Temporal персистит в базе данных, и когда он восстанавливает воркфлоу, он заново проходит по всем шагам от начала и до конца (до места последней остановки или ожидания следующего шага).

Temporal: Введение. Часть 1

#api_design
#system_design

Дизайн API: Как быть, когда есть множество потребителей

Хотя я начал писать о Temporal, решил отвлечься на другую тему, которая с ним мало связана: дизайн API.

В предыдущей статье о Temporal мне задали несколько вопросов о непонятном атрибуте в названии URL, который встретился в тексте прошлой статьи [HttpPost("system.clients.startUserGrantedWorkflow")]. Вопрос был вызван наличием группы system в URL адресе.

Решил пролить свет на эту тему и описать, зачем мы составляем URL-адреса такого вида, чем это обусловлено и какие последствия это может иметь для всего проекта.

Дизайн API: Как быть, когда есть множество потребителей

скомпилировал статьи в блог на github pages, теперь читать будет проще

вот и первое падение в проде: окно даунтайма публичных ссылок составило почти 2 часа, исчерпав почти годовой лимит :(

алертинг в виде подписчиков отработал штатно

Давно ничего не публиковал / писал: с головой утонул в работе. Сейчас, вроде как, немного разгрузился.
Решил воспользоваться помощью чата: накидайте, пожалуйста, тем в комменты, что интересно было бы обсудить и, возможно, почитать в какой-то небольшой статье (архитектуры, требования, mediatr, smth else)

Как насчет работы с jsonb в EF Core для постгрес провайдера, организации структуры БД, подводных камней и некоторых атипичных задач, вроде шифрования данных, версионирования и миграций, concurrency или индексации ?

К сожалению, статья немного задерживается (

Объем получается довольно большим (с учетом примеров), да и некоторые набитые шишки (например, с mutable операциями при создании computed stored columns по tstz типам) не сразу вспомнить удается :)

Постараюсь на этих выходных добить

#ef_core
#db_design
#postgresql

Тонкости JSONB в PostgreSQL и EF Core: Как постичь дзен?

Сегодня мы рассмотрим работу с JSONB в базе данных PostgreSQL совместно с родной для .NET ORM от Microsoft — Entity Framework Core.

Мы разберём, как удобно хранить данные в денормализованном виде, как защититься от параллельных изменений и как поступать, когда необходимо выстраивать отношения между сущностями, чьи атрибуты упакованы в JSONB. Помимо этого, мы затронем такие темы, как optimistic concurrency, data encryption, миграции подобных сущностей и их версионирование.

Итак, начнём.

Тонкости JSONB в PostgreSQL и EF Core: Как постичь дзен?