Как управлять лимитами использования и квотами с помощью S3 для приложений SaaS

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

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

users: пользователи, подписавшиеся на ваше приложение.

подписки: записи о подписках, синхронизированные с вашим платежным провайдером. Каждая запись содержит ссылки на «План» и «Пользователь».

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

функции: это функции вашего приложения, такие как рабочие места, проекты, уведомления по электронной почте и т. д.

plan_features: используется для выражения отношения «многие ко многим» между планами и функциями.

Но подождите, как вы справляетесь с тем, что пользователю разрешено делать в вашем SaaS-приложении?

Как вы гарантируете, что уведомления по электронной почте не будут отправлены для Алисы в плане «Хобби»? Или что Боб на плане «Команда» не создает больше 10 проектов?

Это когда переключатели функций и ограничения использования вступают в бой.

3Типы функций SaaS

Давайте представим три типа функций, обычно встречающихся в приложениях SaaS.

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

1. Ограничение: устанавливается абсолютный лимит на использование функции. Например. вы можете создать только 10 проектов.

1. Квота: это лимиты, в которых использование периодически сбрасывается, например. вы можете синхронизировать информацию до 100 раз в день.

Управление лимитами использования и квотами

О, но разве я не могу использовать платформу для пометки функций, чтобы справиться с этим? Ну да и нет.

Инструмент пометки функций и экспериментов, такой как LaunchDarkly, дает вам возможность блокировать функции, а с помощью [вариаций] (https://docs.launchdarkly.com/home/flags/variations) вы даже можете хранить метаданные, такие как целые числа или JSON, которые будут возвращены. рядом с состоянием функции. Тем не менее, эта функция по-прежнему очень логическая — она либо включена, либо отключена. Вам все равно придется написать код, чтобы определить, превысил ли пользователь свои лимиты или нет, решить, следует ли сохранять события использования или вести текущий счет для каждого пользователя.

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

По сути, это сводится к решению этих подзадач.

Проблема 1: Нам нужно проверить, может ли «Пользователь» получить доступ к «Функции».

Решение. Трехстороннее соединение с базой данных, кэширование поиска или кодирование отношений в инфраструктуру RBAC для повышения эффективности.

Проблема 2: Нам нужно вести подсчет количества раз, когда «Пользователь» использует «Функции».

Решение. Храните счетчики где-нибудь, предпочтительно в базе данных с высокой скоростью чтения-записи, строгой согласованностью и атомарными операциями увеличения/уменьшения. Здесь на ум приходит RDBMS или Redis.

Проблема 3: Нам нужно проверить, не превысил ли «Пользователь» ограничения на «Функции».

Решение: ПО промежуточного слоя/политики на клиенте и сервере, которые проверяют использование «Пользователем» на соответствие предельному значению «Функции».

Проблема 4: Для квот нам необходимо периодически сбрасывать счетчик использования «Пользователя».

Решение. Настройте задание Cron, чтобы сбрасывать использование через нужные промежутки времени.

Теперь представьте, что ваша таблица цен выглядит так:

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

Архитектура системы

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

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

Тем не менее, ключевой особенностью S3 должна быть его строгая согласованность чтения после записи. Это означает, что он идеально подходит для отслеживания упомянутых выше счетчиков использования. По сути, это экономичная альтернатива Redis, хотя и с более низкой производительностью чтения-записи и ограниченными шаблонами доступа (список, установка, размещение, удаление).

Имея в своем распоряжении мощные инструменты, такие как Athena и Glue, вы можете выполнять SQL-запросы непосредственно к данным в S3 или настраивать рабочие процессы ETL для передачи их в хранилище данных.

Компромисс здесь заключается в потере гибкости запросов по сравнению с хранением данных в той же СУБД, что и остальная часть вашего приложения.

Модель данных S3

Итак, какие данные нам нужно хранить на S3?

Во-первых, это матрица объектов, которая представляет собой набор планов и объектов, а также атрибутов этих объектов.

"планы": [

"plan_id": "Хобби",

"Особенности": [

"feature_id": "Места",

"тип": "булев",

"значение": 1

"feature_id": "Проекты",

"тип": "Предел",

"значение": 10

"feature_id": "SyncInsights",

"type": "Дневной лимит",

"значение": 100

"feature_id": "Электронная почта клиента",

"type": "Месячный лимит",

"значение": 200

Во-вторых, для каждого пользователя мы можем хранить карту функций для счетчиков использования. Мы можем использовать идентификатор пользователя в качестве ключа объекта для выполнения поиска O (1) в корзине S3.

"использование": {

«Места»: 5,

«Проекты»: 10,

«СинкИнсайтс»: 15,

"CustomerEmails": 20

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

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

Должен ли я сделать решение своими руками?

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

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