Эффективно ли зеркальное отображение Stripe (подписки, счета, купоны...) в вашей локальной базе данных?

Question

Является ли зеркалирование Stripe вашей собственной локальной базой данных хорошим?

Зеркалирование с использованием вызовов API (создание нового плана, купона, подписки и т. Д.) И веб-крючков (новый счет-фактура или сгенерированный платеж, сбой платежа). Таким образом, вы можете хранить все данные (буквально иметь похожие таблицы со столбцами, соответствующими объектам полосы) и работать с ним быстрее.

Если нет, то какие данные вы сохраняете локально и что запрашиваете?

Спасибо.

Answer 1

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

Что, как говорится,

1. Вы не контролируете данные, сохраненные на стороне Stripe. Если он исчезает по какой-либо причине, у вас проблемы. Хотя такое событие маловероятно, я бы порекомендовал хранить на месте наиболее важную информацию.

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

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

Answer 2

Стратегия, которую вы описываете, именно та, которую я использую.

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

Чтобы не выбирать, какие поля клиента или подписки сохранять в БД, я сохраняю весь JSON в PostgreSQL с помощью JSONBполе. Накладных расходов на производительность почти нет, а запрашивать данные очень просто.

Делая это, вы получаете лучшее из обоих миров:

• Скорость (поскольку вы читаете локальные данные вместо удаленных данных)
• Простота разработки (вам не нужно много думать о том, какие данные Stripe вы собираетесь сохранить)
• Вы в безопасности в случае катастрофы на стороне Stripe
• Ваши данные всегда актуальны

На самом деле я даже написал статью об этом, если это поможет:https://juliensalinas.com/en/storing-stripe-payment-data-database/

Answer 3

Как сказал Андрей, приятно не беспокоиться о дублировании данных. Их API достаточно быстр для большинства случаев использования, но если вам нужно сделать это быстрее, вы можете создавать временные кеши с помощью redis или memcached. Это особенно важно, если у API Stripe возникли неожиданные простои.

Большинство SaaS-компаний, таких как Stripe, в качестве дополнительной меры предосторожности рекомендуют создавать резервные копии ваших данных. Поэтому, если некоторые из ваших данных Stripe были случайно удалены, или был изменен контакт Salesforce и т. Д., Вы всегда можете восстановить их из резервной копии. Это также распространяется на вас в очень маловероятном случае компрометации данных Stripe.

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