Побудувала рівень платежів і прав доступу — Stripe поряд із внутрішньозастосунковими покупками Apple і Google — обмеживши каталог, пошук та експорт моделлю доступу з 11 таблиць, яку перевіряє сервер.

Ситуація. Гроші — це та частина платформи, до якої ніхто не може собі дозволити ставитися абияк. Підписка мусить пережити закінчення строку дії картки, повернення коштів, зміну тарифу, вебхук, що прийшов двічі, і вебхук, що прийшов не в тому порядку. Щойно платити можна в трьох вітринах — карткою у вебі, через Apple в одному магазині застосунків, через Google в іншому, — з’являються три різні версії того, що людина купила, а продуктові однаково потрібна одна відповідь на одне запитання: що цій людині можна робити просто зараз?

Завдання. Приймання платежів і надання прав мали бути двома окремими системами, а не однією, щоб нова вітрина не вимагала переписувати кожну перевірку доступу в продукті.

Дія. Картки й підписки обробляє Stripe через 18 файлів на Go, а покупки в застосунках Apple і Google надходять через власну перевірку квитанцій. Усі три потоки сходяться в схемі payments із 9 таблиць і 34 функцій — і далі не йдуть. А продукт насправді звертається до окремої схеми access — 11 таблиць і 34 функції, — яка відповідає на запитання «чи може цей обліковий запис це зробити?», не знаючи й не зважаючи на те, яка вітрина за це заплатила. Від цієї відповіді залежить доступ до каталогу компаній, пошуку й експорту даних, і сервер перевіряє її заново під час кожного запиту, бо прихована кнопка — це люб’язність, а не засіб контролю.

Результат. Нова вітрина тепер зачіпає лише платіжну частину й не чіпає перевірок доступу, а щоб відповісти на запит до підтримки про чийсь доступ, досить зазирнути в одну таблицю, а не в три. Ціна — дві схеми там, де меншому продуктові вистачило б однієї, і перевірка прав у запитах, які без неї нічого б не коштували.