Тест на List.AsQueryable() зелёный, а на проде всплывают LINQ-трансляция, null, collation, unique index и два воркера, забравшие один платёж. Разбираю, где in-memory тесты помогают, а где начинают врать.

Осенью 2022-го мы добавляли в наш платёжный агрегатор новый способ оплаты: плательщик уходит по ссылке в приложение своего банка, подтверждает платёж там, а банк присылает нам нотификацию о результате. Песочница у банка была, формально. Отвечала статусами из позапрошлой версии протокола, а нотификации не присылала вообще; обещанные доработки ехали к нам дольше, чем наш дедлайн. Мы перестали ждать и написали двойника провайдера сами - по PDF со спекой, с тестом на каждый сценарий из документации. CI зелёный. Запускались осторожно, тремя волнами мерчантов: первые две прошли тихо. После третьей в саппорт пошли тикеты: у плательщика деньги списаны, у мерчанта платёж висит.

Сколько раз вы реально меняли базу под приложением? Generic Repository – первое, что тащат в проект, и последнее, в чём сомневаются, – держат ровно ради этого. У меня за карьеру смена базы случилась дважды, и оба раза репозиторий полетел в корзину вместе со всем слоем. Это лишь первое из трёх обещаний, которое он не сдержал, а по дороге тихо забрал доменную модель. Как именно – на реальном кейсе с Mongo, и чем мы его заменили.

Anti-corruption layer в учебниках выглядит как одна аккуратная коробка между чужой системой и вашей: всё чужое остаётся снаружи, внутрь проходит только то, что уже переведено на язык вашего домена. Граница ровная, как по линейке. Почти за год, что мы вытесняли 10-летний Rails-монолит на .NET, такой ровной границы я не увидел ни разу – ни у себя, ни, кажется, у кого-то ещё на живом проекте.

Понятно это стало в первую же неделю. Мы открыли таблицу exercises и нашли в одной JSONB-колонке 14 разных форм одного типа задания, слепленных за 10 лет. Смаппить это в новые DTO как есть – и новая модель отрастит ровно ту же форму, что у Rails. “Нужен ACL”, подумали мы. Только, как выяснилось на практике, не один.

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

Полгода после MVP, первые крупные клиенты. B2B travel SaaS, конец 2016-го. Компании начали подключать не по 15–20 человек, а по 80–100.

Один из новых клиентов оказался кратно крупнее остальных — финансовый департамент почти на сотню человек с фиксированным квартальным бюджетом на командировки порядка нескольких сотен тысяч рублей. К середине квартала большая часть бюджета уже потрачена, остаток — заметно меньше половины. Два руководителя — в разных городах, в разных браузерах — одновременно открывают форму апрува командировок. Оба видят один и тот же остаток. Один одобряет крупную поездку, другой почти в то же время — ещё одну, сопоставимую по сумме; каждая по отдельности в остаток вписывалась. Оба получают подтверждение. Вместе две поездки пробили лимит — перерасход, которого ни один из руководителей в одиночку не допускал.

Обнаружили через 3–4 часа — когда финансовый менеджер клиента открыл квартальную сводку и позвонил нам.

Пятница, 23:47. PagerDuty: “Платёж AmEx, провайдер вернул 5xx три раза подряд, билеты не зарезервированы.” Открываю логи – действительно три ответа провайдера 5xx, ни одной успешной транзакции по нашей базе. Закрываю как временный сбой на стороне провайдера, пишу короткую сводку в дежурный чат и иду досматривать. Через 40 минут второй алерт – уже от ночной поддержки: клиент прислал скрин выписки, 3 списания подряд за одну бронь. У клиента рейс через 6 часов, ему нужна действующая бронь и подтверждение, что он завтра нормально улетит, а не тикет в поддержку.

Мы делали B2B-платформу для деловых поездок: бронь авиа, отели, трансфер, страховка, в финале – оплата корпоративной картой через платежный шлюз. С этой ночи началась история, которая закончилась переписыванием всего платёжного слоя нашего booking-сервиса. По дороге мы поймали 5 граблей.