Yet another SA

Integrations must go on

Давно хотел сделать программу по продвинутым интеграциям, где можно покопаться в технических деталях и поговорить о связи с архитектурой. Пока базовый курс в творческом отпуске, го на продолжение - Интеграции Систем. Next Level

Что внутри:

◽️Инфра, сети, протоколы, мониторинг

◽️Надежность и производительность: кеширование, балансировка, работа в режиме сбоев

◽️Брокеры сообщений в теории и практике: Kafka и RabbitMQ

◽️Интеграции и распределенные системы. CAP и PACELC теоремы.

◽️Управление бизнес транзакциями. Оркестрация и хореография

Курс для тех, кому интересно вот это все. И кто имеет уверенный опыт проектирования взаимодействий поверх HTTP.

📆 16 ноября - 14 декабря по четвергам и субботам

🔗 Рега тут

Утро начинается с кэша

Годная лекция о кэшировании от основ до сложностей реализации. Что интересного:

• Стратегии кеширования
• Считаем, когда кэш вреден
• Вытеснение данных из кэша
• Инвалидация кэша

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

#архитектура

#оффтоп #манагерское

Как же интересно работает мозг. Встретил тезис в духе:

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

Поток мыслей:

- Надо срочно ответить, в инете кто-то неправ!

- Как же хорошо, что большинство близких коллег не из этих

- Надеюсь, больше никогда не попаду в такой коллектив

- Интересно, как у людей формируется такая позиция?

- Подозреваю, ее формируют процессы, коммуникации и культура в компании

- Интересно, на сколько часто в моих командах складывалось такое отношение? Как избежать это или изменить?

Хотел набросить, ушел рефлексировать. Жизнь боль.

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

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

Как правильно выбрать хранилище под задачу

Словом идемпотентность уже никого не напугаешь. Все разобрались, что это и почему важно. А важно для ретраев. А эффективная организация ретраев - тот еще адок.

Тот самый Вася из Яндекса разбирает проблемы, которые могут вызывать ретраи при падениях системы, показывает варианты решения, сравнивает на графиках и циферках. Из интересного:

◽️Exponential backoff - чтобы адекватно настроить время между ретраями

◽️Сircuit breaker и adaptive retry - чтобы не положить сервис ретраями

◽️Deadline propagation - думал, что это фишка gRPC, но нет

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

#интеграция #архитектура

Вводная (по мнению автора) статья о способах балансировки трафика. Хотя большинству смертных никогда не придется заглядывать глубже, если это не админы, сетевые архитекторы и т.п.

Многобукв для тех, кто хочет окунуться в тему:

- Балансировка, и зачем это нужно
- Функции балансеров
- L7 / L4 балансеры и зоны применения
- Типовые топологии и способы масштабирования

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

#интеграция #архитектура #сети

Не могу не репостнуть

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

- Как закладывать надежность на старте проектирования

- Где искать надежность при взаимодействии сервисов

- Latency based Congestion Control - не буду это переводить

- Архитектурная ката для участников

Если соберетесь подключиться, то орги скидос подогнали - techlead_crew_7_BsrEcL

Прошлогодний рассказ, как Сбер делает копайлота для юристов. Никакой магии, только эксперименты с RAG и пайплайнами + формирование базы знаний. Характерно, что для формирования базы знаний понадобилась ручная разметка базы знаний силами 30 юристов - обыватель без экспертизы в домене не подойдет.

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

Хозяйке на заметку:
- Про RAG совсем на бизнесовом
- Совсем кратко про построение боевых LLM-приложений

AI-продукты для разрабов пошли дальше всяких копайлотов. Replit предлагают вроде уже стандартную связку IDE + репа + AI-ассистент. А еще их агент по текстовому описанию пишет код, поднимает БД и разворачивает приложение. Все под ключ для ленивого разраба.

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

Ссыль: https://replit.com

Статья (нужен vpn) о ретраях и защите от дублирования транзакций из недр Airbnb. В том числе разбирают проблемы реализации идемпотентности, и почему это не просто ключик в запрос положить. В том числе, использование распределенных хранилищ.

Заодно вспомним историю Васи и его борьбе с идемпотентностью в Яндекс.Такси, тоже полезно

Интересный, пусть и поверхностный рассказ, как делают реальные приложения на основе LLM.

https://youtu.be/sNwgkLniGqQ?si=bPOB88QLDL3HH2SS

Знакомый поделился прекрасным. Однажды он обнаружил сервис с методом:

GET /api/getClientInfo?clientId=123

Попробуйте угадать, что он делает:
1. Если клиент не существует
2. Если клиент существует

Дада, вы все правильно поняли:
1. Сервис создает клиента
2. Сервис открывает клиенту счет

Чтобы не творить такую дичь, запрыгивайте на тренинг по проектированию REST API. Разберем, как API может довести потребителя до паралича, и научимся делать его простым и удобным.

А вы какие шедевры встречали в практике?

Кажется, что-то интересное намечается

https://mts-digital.ru/events/details?id=742631

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

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

#архитектура