Пятничное чтиво

Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.

—————————————

Как защитить платежный API от двойных списаний с помощью идемпотентности

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

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

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

#communications #idempotency

—————————————

Работа с унаследованным кодом: Риски, анализ проекта и стратегии работы

Рубрика «интернет археология» в канале. По ссылке выше — пост 12 летней давности (2014 год), в которой автор описывает собственное представление легаси и как с ним работать. Предвосхищая вопрос «а зачем об этом думать, когда нейронкам это не надо?»: в тексте есть секция с анализом, который может сделать нейронка. Но вот знать что именно анализировать и зачем — тут нейронка не поможет.

Сам текст состоит из 4 частей: определение легаси, риски легаси, анализ и что с легаси делать (и как). В определении легаси пункты очевидны (отстутвие документации, тестов, старые технологии, код «плохой»). Также описаны 4 варианта появления легаси. В рисках описывается что не так может пойти с легаси (ттм, который ниже требуемого, потеря денег и так далее). В секции анализа, автор, предлагает задать 10 вопросов о технической составляющей системы, по которым можно сказать на сколько система поддерживаема. В последней части предлагается четыре способа взаимодействия с легаси (оставить, переписать с нуля и два подхода модульного переписывания. В конце найдете список литературы.

#modernization #legacy

—————————————

Systems Thinking in Accident Investigations

В изменении системы, не важно будет это фиксом багов, упавшим продом и добавлением функционала, придется ответить на вопрос: «а почему система раньше работала таким образом». Но, к сожалению, этому вопросу уделяют больше внимания, когда говорят об авариях. Статья выше — попытка посмотреть на расследования аварий со стороны системного мышления. И спойлер главной идеи в том, что аварии случаются как сумма факторов, которые не отловили до.

Вообще, текст строится вокруг расследования инцидента, произошедшего во время Alaska Airlines Flight 1282 рейса. На высоте 4.5 км произошла разгерметизация, в результате чего, дверь в середине корпуса «вылетела». Причина оказалась в том, что забыли установить 4 болта, но ценность текста не в причине, а в том, как люди думали «почему это произошло». Благодаря этому, автор подводит к «многоуровневой защите», где катастрофа проходит через «стены», которые должны были ловить проблему до аварии. Но в случае катастроф — ошибка, проходя через «стены», приводят к жертвам. Ну и понравилась итоговая мысль о том, что отчеты по инцидентам раскрывают скрытую структуру изучаемой системы.

#system_thinking