Things I Wished More Developers Knew About Databases

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

— Вам повезло, если 99.999% времени нет проблем в сети
— ACID имеет много значений
— Каждая DB имеет разные возможности consistency и isolation
— Оптимистичная блокировка — это вариант, когда вы не можете взять обычную блокировку
— Есть аномалии помимо грязных чтений и потери данных
— Моя база и я не всегда согласны с порядком элементов
— Шардинг на уровне приложения может жить вне приложения
— AUTOINCREMENT может быть вредным
— Устаревшие данные могут быть полезными и lock-free
— Между любыми источниками синхронизации происходят расхождения времени.
— Lantency имеет много значений
— Оцените требования к перформансу каждой транзакции
— Вложенные транзакции могут быть вредными
— Транзакции не должны поддерживать состояние приложения
— Query planners могут сказать много о базах данных
— Онлайн миграции сложные, но возможные
— Значительный рост базы приводит к непредсказуемости

https://medium.com/@rakyll/things-i-wished-more-developers-knew-about-databases-2d0178464f78

#article #databases #medium #en

Books in Software Architecture
https://medium.com/@nvashanin/books-in-software-architecture-6ad974e524ce

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

🥇 Software Architecture in Practice (3rd Edition) (SEI Series in Software Engineering) - Len Bass, Paul Clements, Rick Kazman
🥈 Essential Software Architecture - Ian Gorton
🥈 Patterns of Enterprise Application Architecture - Martin Fowler
🥇 Domain-Driven Design: Tackling Complexity in the Heart of Software - Eric Evans
🥇 Stakeholder Theory: The State of the Art - R. Edward Freeman, Jeffrey S. Harrison, Andrew C. Wicks, Bidhan L. Parmar, Simone de Colle
🥈 Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development - Craig Larman
🥈 Documenting Software Architectures: Views and Beyond - Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord
🥉 Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives - Nick Rozanski, Eóin Woods
🥈 Designing Software Architectures: A Practical Approach (SEI Series in Software Engineering) - Humberto Cervantes, Rick Kazman
🥇 Software Estimation: Demystifying the Black Art - Steve McConnell
🥇 Site Reliability Engineering- Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy
🥉 Enterprise Architecture As Strategy: Creating a Foundation for Business Execution - Jeanne W. Ross, Peter Weill, David Robertson
🥉 Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems - Martin Kleppmann

#books #medium #en

https://medium.com/@nvashanin/books-in-software-architecture-6ad974e524ce

Что же такое этот GraphQL?
https://www.freecodecamp.org/news/so-whats-this-graphql-thing-i-keep-hearing-about-baf4d36c20cf/

GraphQL — это язык запросов, разрабатываемый компанией Facebook, зарелизившийся на широкую аудиторию в 2015 году и стремительно набирающий популярность последние несколько лет.
Обычно, его рассматривают как альтернативу REST API для взаимодействия разных компонентов вашей архитектуры.

Простой запрос на GraphQL

 {
  posts { # this is an array
    noscript
    body
    author { # we can go deeper!
      name
      avatarUrl
      profileUrl
    }
  }
}

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

Но тогда возникают слишком тяжелые endpoint'ы?- спросите вы. В REST подобную проблему можно было бы решить в помощью API Composition. GraphQL предоставляет инструмент резолверов.

Resolvers позволяют сматчить поля в запросе GraphQL на непосредственные фетчеры этих полей. Фактически, это функции, которые дают понять где и как найти те данные, которые запрашивает клиент.

Пример резолверов

 {
  post(root, args) {
    return Posts.find({ id: args.id });
  }
},
Post: {
  author(post) {
    return Users.find({ id: post.authorId})
  }
}

Это может быть поход в базу данных или даже запрос в сторонний сервис.

#graphql #microservices #practices #rest #en #ru

https://www.freecodecamp.org/news/so-whats-this-graphql-thing-i-keep-hearing-about-baf4d36c20cf/
(перевод: https://habr.com/en/post/326986/)
https://medium.com/free-code-camp/why-graphql-is-the-future-of-apis-6a900fb0bc81
https://itnext.io/graphql-in-a-microservices-architecture-d17922b886eb

🧑‍🚀
Сегодня Святослав Фельдшеров рассказывает о разработке альтернативной вселенной микросервисов в поиске Яндекса. Он напомнит 6 основных проблем традиционной микросервисной инфраструктуры, решение которых и привело нас к технологии Apphost.

11 причин почему вы можете потерпеть неудачу с микросервисами

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

1. Менеджмент недооценивает сложность разработки микросервисов (камнем преткновения становится сложность поднятия разных частей проекта для локальной разработки)
2. Нет процесса обновления библиотек и инструментов до последних версий
3. Использование общих (коммунальных) сервисов для разработки
4. Недостаточность визибилити структуры микросервисов в системе контроля версий
5. Нет четкого определения что такое микросервис
6. Нет четкой стратегии по переиспользованию кода
7. Нет явного ограничения в используемых технологиях
8. Зависимость между людьми (команды сильно фокусируются только на своих частях и никто не смотрит на общую картину)
9. Отсутсвие документации
10. Функциональность важнее платформы
11. Отсутсвие автоматического тестирования

https://medium.com/xebia-engineering/11-reasons-why-you-are-going-to-fail-with-microservices-29b93876268b

#article #practices #medium #en

Знакомство с Greenplum
Попалась неплохая открытая вводная лекция про базу данных для аналитики на основе PostgreSQL - Greenplum.
Понятно рассказывается про то, что такое аналитические MPP базы данных, как с их помощью строят Data Lake (с примерами из Uber и Avito), и как построена архитектура таких БД на примере Greenplum.

https://www.youtube.com/watch?v=qpwA1z3s4uA
и чуть более сложно про внутреннюю архитектуру: https://www.youtube.com/watch?v=k9ckMfD-qf4

#video #mpp #greenplum #datalake #ru

Глубокое погружение в индексы MongoDB
https://medium.com/swlh/mongodb-indexes-deep-dive-understanding-indexes-9bcec6ed7aa6

В статье про индексы MongoDB описываются некоторые базовые аспекты движка: структура данных, хранение на диске, загрузка в память. Некоторая выжимка:
Структура данных:
— B-Tree структура индексов с алгоритмической сложностью поиска O(logN).
Хранение на диске:
— Использование prefix index compression позволяет не дублировать информацию, сохраняя одинаковые префиксы только один раз.
Загрузка в память
— Индексы работают отлично только когда помещаются в память. В других случаях нужно думать про то, как правильно организовать поиск, чтобы держать на минимуме IO диска.

#database #mongodb #medium #en

CAP теорема в распределенных системах.

Осознал, что не было публикаций про такие базовые вещи, как CAP теорема. Теорема Брюера (более известная под названием CAP теорема) говорит нам о том, что в распределенной системе можно выбрать достижение не более 2 из:
- Consistency. Согласованность. (во всех узлах распределенной системы информация не противоречит друг другу),
- Availability. Доступность (любой запрос к распределенной системе завершается ответом),
- Partition tolerance. Устойчивость к разделению (расщепление распределенной системы не приводит к недоступности отдельных узлов).

https://medium.com/swlh/cap-theorem-in-distributed-systems-edd967e7bdf4
https://habr.com/en/post/328792/
https://habr.com/ru/post/258145/

#theorem #distributed #cap #medium #habr #ru #en

Event-based Microservices: обработка ошибок

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

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

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

В статье приводится два способа обработки приведенных выше типов ошибок:

Retry Events.
Основной смысл в том, что мы помечаем событие как обработанное, вынимаем его из пайплайна и прикапываем где-то в стороне как "требующее повторной обработки". Это специальное сообщение содержит всю информацию о первоначальном событии, чтобы чуть позже (например, когда сеть восстановится) его можно было легко повторить. Если после нескольких повторов сообщение не обрабатывается успешно, его стоит обработать как dead letter.

Dead letter events.
Основной смысл такой же - помечаем события как обработанные, вынимаем из пайплайна, прикапываем в стороне. При сообщения такого рода должны зажигать алертинги и привлекать людей к починке проблемы. Сообщения можно также повторить, отправив в пайплайн после устранения первоочередной проблемы.

https://medium.com/usertesting-engineering/event-based-microservices-error-handling-7c84e3cb1332
https://docs.microsoft.com/ru-ru/azure/event-grid/manage-event-delivery

#article #practices #distributed #microservices #medium #en

Scaling Cache Infrastructure at Pinterest
https://medium.com/pinterest-engineering/scaling-cache-infrastructure-at-pinterest-422d6d294ece

Pinterest опубликовал на днях интересную статью о том, как выглядит их инфраструктура кэшей.
Для понимания, Pinterest — социальная сеть, фотохостинг: тысячи машин, кэширование сотни терабайт данных и более чем 150кк rps в пике.
Слой stateful кэширования играет ключевую роль в перформансе и экономии ресурсов для подобной нагрузки.

Система построена на предоставлении персистентного уровня кэширования как сервиса. Такой отдельно стоящий сервис легко независимо масштабировать. Используется memcached как key-value хранилище и mcrouter как application layer proxy (layer 7) для обеспечения роутинга запросов в пуле memcached инстансов.

Почему memcached:
— асинхронная архитектура очень эффективна для горизонтального масштабирования. Производительность Memcached на r5.2xlarge EC2 инстансе: 100к rps и десятки тысяч одновременных TCP соединений без ощутимых проблем на стороне клиента.
— Extstore помогает гибко настроить выгрузку значений из memcached на диск, что помогает достичь максимальной эффективности используемых ресурсов и увеличить размер используемого пространства на инстансе с ~55 GB (r5.2xlarge) до примерно 1.7 TB (i3.2xlarge).
— Сам по себе memcached — очень простое key-value хранилище, которое ничего не знает про то, в какой системе и с кем в кластере он работает.
— Большое комьюнити и надежность, проверенная годами на продакшн серверах.

Mcrouter позволяет построить пул memcached инстансов, используя консистентное хэширование ключей (о котором мы говорили вот тут) и оставлять большинство ключей нетронутым при добавлении нового инстанса memcached в кластер и перебалансировки нагрузки.

https://medium.com/pinterest-engineering/scaling-cache-infrastructure-at-pinterest-422d6d294ece

#article #practices #distributed #cache #mcrouter #memcache #medium #en

Целостность данных в микросервисах или как не дать неконсистентным данным сломать сервис

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

Для примера, рассмотрим сервис аренды машин, где используется принцип database per service:
- Микросервис geoareas владеет данными о разных географических полигонах - городах, районах: {id, geometry}
- Микросервис tariffs в свою очередь распоряжается данными о стоимости аренды: {id, geoarea_id, price_per_minute}. Есть зависимость от сервиса geoareas.

В какой-то момент нам понадобилось удалить объект из микросервиса geoareas - вызвать endpoint: DELETE /geoarea?id={id}.
Это может повлечь ряд проблем вплоть до недоступности микросервиса, т.к. у нас останутся тарифы, указывающие на удаленную геозону.

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

В базах данных, кстати, есть автоматический контроль целостности с помощью внешних ключей.

У нас же распределенная микросервисная архитектура и есть несколько вариантов решения:

1. Webhooks

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

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

 target="pre-delete" action="POST tariffs/check_delete?geoarea_id={id}"

В микросервисе tariffs, соответственно, нужно реализовать endpoint /check_delete для проверки того, что зону можно удалить и микросервис tariffs "не против".

Унифицированность таких хуков позволяет легко конфигурировать их на лету. При появлении нового микросервиса, который использует geoareas добавлять в список хуков новую проверку.

Таким образом, geoareas поддерживает механизм унифицированных веб-хуков, но ничего не знает про то, что за логика внутри этих хуков.

2. Reference Counting

В этом варианте мы будем следить за тем, кто использует геозоны.
Расширяем API нашего микросервиса geoareas следующими endpoints:

 /hold?geoarea_id={id}&holder={holder}
POST /release?geoarea_id={id}&holder={holder}

Таким образом, если хотим создать новый тариф в зоне, то перед этим нужно эту зону заблокировать в сервисе geoareas, например:

 /hold?geoarea_id=moscow&holder=tariffs_tariffmoscow1

Рядом с геозонами в микросервисе geoareas будем хранить список тех, кто "держит" эти геозоны.
При попытке удаления геозоны проверяем список держателей и не даем удалять, если список не пуст.
Если тариф, держащий геозону, удаляется, то после удаления нужно отпустить блокировку, например:

 /release?geoarea_id=moscow&holder=tariffs_tariffmoscow1

Базы данных. Тенденции общемировые и в России.

Если кто-то пропустил - хорошая статья про текущие тренды в мире баз данных.
И если сильным ростом хранилищ с SSD по отношению к HDD никого не увидишь, то совсем другое дело рост рынка облачных решений в 2 раза за 5 лет.

https://habr.com/en/post/533880/

#article #database #habr #ru

Tarantool vs Redis: что умеют in-memory технологии

Очередная хорошая статья на хабре про бд, а именно in-memory технологии - Redis и Tarantool. Это базы, которые весь объём данных хранят целиком в оперативной памяти. Размер такой базы лимитирован ёмкостью оперативной памяти узла, что может ограничивать нас в количестве данных, но увеличивает скорость на порядок.

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

https://habr.com/en/company/mailru/blog/550062/

#article #database #habr #ru #redis #tarantool

Алгоритм консенсуса в распределенных системах — Пакcос (Paxos).

Паксос — алгоритм принятия решений в распределённых системах, лежащий в основе многих современных инструментов — Consul, Zookeeper, etcd и других.

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

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

Алгоритм Паксос (Paxos), придуманный и доказанный Лесли Лампортом, говорит нам о том, как этого консенсуса можно достичь. Критерием достижения является согласие с предложением более половины участников.

Алгоритм состоит из двух этапов:

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

Предложение:
1. Предлагающий, получив ответы от большинства принимающих, выбирает в качестве значения предложения v значение из ответа с максимальным номером предложения и рассылает предложение (n, v).
2. Принимающий, получив предложение (n, v), обязан принять его если он, конечно, не пообещал другому предлагающему не принимать предложений с номерами меньшими n, где n > n.

Интересные моменты:
— Консенсуса можно вовсе не достигнуть из-за большого количества предлагающих. Для решения этой проблемы можно ввести случайные задержки.
— Повреждение данных на доле узлов может расколоть вашу систему на несколько частей.

Ссылки:
https://habr.com/ru/post/346180/
https://lamport.azurewebsites.net/pubs/paxos-simple.pdf
https://en.wikipedia.org/wiki/Paxos_(computer_science)

Доклад на ближайшем Highload++ “Паксос в картинках” (https://www.highload.ru/spring/2021/abstracts/7677) Консантина Осипова.

#consensus #algorithm #highload #microservices #distributed #habr #ru #en

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

Канал по-прежнему открыт для всех желающих и в него можно приглашать друзей и коллег, если вы этого еще не сделали: https://news.1rj.ru/str/startup_architecture

Introduction to Fulfillment at Uber

Несколько недель назад Uber выпустила большую статью про переосмысление Fulfillment платформы 2014 года, на которой строятся основные бизнес-сценарии компании. Из-за роста функциональности (аэропорты, еда, доставка…) платформа перестала легко масштабироваться.

Вводные:
— Более миллиона одновременных пользователей и миллиарды поездок в год по более чем десяти тысячам городов.
— Миллиарды транзакций БД в день.
— Сотни микросервисов полагаются на платформу как на источник информации о поездках и водителях.
— События, генерируемые платформой, используются для создания сотен офлайновых датасетов данных для принятия бизнес-решений.
— Более 500 разработчиков расширяют платформу.

Проблемы старой архитектуры:
— Проблемы согласованности — вся архитектура была построена на предпосылке, что можно жертвовать согласованностью в пользу доступности и задержки.
— Multi-Entity Writes — например, сага паттерн, контролирующий логическую транзацию между микросервисами. С ростом бизнеса такие транзакции становились все больше по размеру и сложнее диагностируемыми.
— Проблемы масштабируемости — ringpop страдает от ограничений, из-за которых были проблемы при перемасштабировании распределенных по городам "подов".

Какие основные решения были приняты:
— Использовать Google Cloud Spanner как основную БД.
— Использовать диаграммы состояний (Statecharts) для объектов бизнеса (каждый объект задается как набор состояний, переходов состояний и триггеров.
— Transaction Coordinator — координатор переходов бизнес сущностей между состояниями.
— ORM layer для абстракции над БД.

https://eng.uber.com/fulfillment-platform-rearchitecture/

#uber #microservices #practices #highload #distributed #en

V8 в бэкенде С++: от одного JS-скрипта до фреймворка онлайн-вычислений.

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

Одной из таких платформ является js-pipeline. Система выносит управление бизнес логикой приложения уровень выше. Вместо того, чтобы описывать бизнес логику разработчиком на каком-нибудь C++, мы выносим большую часть бизнес логики в веб-интерфейс. Теперь новую бизнес логику можно описывать на JavaScript прямо из админки.

Это невероятно снижает time to market. Новая бизнес логика долгого деплоя может быть раскатана на пользователей буквально через несколько минут после самой идеи.
Все это сильно прибавляет скорости разработки и открывает огромные просторы для бизнеса.

Сегодня мой коллега Ислам приоткрывает завесу над технической частью этого большого проекта. Лайки и комментарии строго приветствуются =)

https://habr.com/ru/company/yandex/blog/572880/

#practices #highload #javanoscript #platform #distributed #article #habr #ru

Rate limiting с Congestion Control

В микросервисной архитектуре встречаются «лавинообразные» падения. Это, например, когда один сервис не вывозит нагрузку и начинает долго обрабатывать запрос, а его клиенты, вместо того, чтобы перестать нагружать сервис, начинают его ретраить, тем самым создавая еще большую нагрузку.
Проблему можно решать несколькими путями. Со стороны клиентов — реализуя классический Circuit Breaker, о котором не так давно был пост.
Со стороны самого запрашиваемого ресурса - это может быть Rate Limiting, или чуть более умный Rate Limiting, про него сегодня и поговорим.

Rate Limiting, как следует из названия — это ограничение количества обрабатываемых операций (единичных запросов, батчей или даже размеров данных за единицу времени). В микросервисах часто предполагается, что если сервису приходит за какое-то временное окно больше N запросов (далее для простоты RPS), то сервис просто «бесплатно» откидывает остальные запросы.

Основная сложность с тем, чтобы выбрать этот самый ограничивающий N.

* Можно провести нагрузочное тестирование и понять количество RPS, больше которых сервис уже не переваривает.
* Еще можно накинуть какой-то процент к пиковым нагрузкам и выбрать это за N.
* Можно даже просто как-то посчитать.

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

Один из вариантов, это своего рода эвристический механизм Congestion control.

Механизм отслеживает «загруженность» каждого конкретного инстанса каждого конкретного микросервиса. (это может быть CPU, у нас это загруженность «основного процессора задач» нашего веб-фреймворка). Если инстанс самодиагностирует, что он не справляется с нагрузкой (превышен порог задач в очереди), начинает срабатывать лимит RPS. Лимит уменьшается до тех пор, пока инстанс не начнет чувствовать себя лучше. Если инстанс справляется с нагрузкой, лимит постепенно увеличивается. Если долгое время не было перегруза, лимит RPS снимается.

Стоит также обратить внимание, что механизм плохо подходит, если:
- есть требования точного ограничения RPS. Эвристика сильно зависит от того, сколько и в каком режиме используется CPU в текущем контейнере.
- CPU не является ограничивающим ресурсом.
- Не требуется стабильное время отклика. Например, сервис обрабатывает события батчами, батчи могут приходить неравномерно. При этом пиково CPU может быть перегружен, но в среднем ресурсов хватает на обработку потока событий.
- Нагрузка на CPU в процессе обработки запроса продолжается десятки секунд. Механизм предполагает, что ручки отрабатывают быстро, и изменение лимита RPS очень быстро повлияет на загруженность CPU (секунды или доли секунды). Если endpoint отрабатывает длительное время, то обратная связь будет происходить медленно, и сходимость RPS к максимальному RPS не гарантируется.

#practices #highload #microservices #distributed #ru

409 Conflict в API

The request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. https://httpstatuses.com/409

Часто при дизайне API забывают о 409. Если в описании интерфейса пропущен этот код ошибки, то это очень сильный сигнал к тому, что в API есть гонки.

Упрощенный пример с гонкой:
Обновления состояния какого-то объекта
POST update_something?new_value=

Пример почему так делать может быть плохо:

Есть endpoint, который управляет скидками в сервисе: флаг включения скидки и размер самой скидки
POST update_discount?enable=[OPTIONAL]&value=[OPTIONAL]

2 человека, которые видят в веб-интерфейсе одно и то же начальное значение: {enable=false, value=0}.

Один из них хочет изменить {enable=true}, понимания, что новое значение не поменяет поведения, потому что размер скидки установлен 0.
Вызывает POST update_discount?enable=true

Другой хочет установить value=30 и только через какое-то время включить саму скидку.
Вызывает POST update_discount?value=30

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

В хорошем интерфейсе клиент должен понимать, что конкретно он меняет и на что.
Одним из хороших вариантов тут — иметь версию изменяемого объекта. Если версия по каким-то причинам изменилась на бэкенде, то самое время вспомнить про 409 ошибку.

Как может выглядеть интерфейс:
POST update_discount?enable=[OPTIONAL]&value=[OPTIONAL]&version=[REQUIRED]

Клиент явно передает номер версии объекта, который он меняет. Если версия на бэкенде почему-то отличается от той, что присылает клиент, то нужно вернуть 409, чтобы клиент обновил более актуальную версию. В каких-то веб-интерфейсах пользователи часто видят «Версия документа устарела, обновить».

#practices #api #distributed #microservices

Привет, у нас тут с вами даже собралось небольшое комьюнити и я хочу спросить. А какие ресурсы вы читаете/смотрите для того, чтобы развиваться в плане архитектуры систем? Разные практики, мнения, новости? Давайте попробуем собрать какие-то ссылки в комментариях к этому сообщению.

#ссылки #practices