Разработка системы биллинга Node-as-a-Service

Запустить ноду несложно. Сложно правильно считать деньги — особенно когда unit of consumption это не запрос, а время работы ноды, тип сети, версия клиента и тариф, который выбрал пользователь три недели назад. NaaS биллинг провален в большинстве молодых провайдеров не потому что задача технически трудная, а потому что между "считать деньги примерно верно" и "считать деньги точно и прозрачно" — пропасть в несколько месяцев инженерной работы. Мы разрабатываем системы биллинга для NaaS уже много лет и знаем, как избежать типовых ошибок. За это время реализовали более 20 проектов, от простых MVP до полноценных crypto-native платформ. В этой статье разберем архитектуру, с которой не стыдно выходить в production, модели тарификации, которые выбирают зрелые провайдеры, и подводные камни, которые ломают биллинг в продакшене. Вы узнаете, как построить слой сбора метрик без потери данных, настроить rating engine на PostgreSQL и интегрировать crypto-платежи в USDC. Также расскажем, какие проблемы возникают с clock skew и duplicate events, и как их решить.

Какие модели тарификации используются в NaaS?

Pay-per-request — классика для RPC провайдеров (Alchemy, Infura, QuickNode). Считаем количество JSON-RPC вызовов, с весовыми коэффициентами по методам:

eth_getLogs с широким диапазоном блоков — это атака на ноду. Без весовых коэффициентов пользователь может сделать один запрос стоимостью тысячи "обычных". Alchemy называет это Compute Units, QuickNode — Credits. Названия разные, смысл один.

Time-based (subscription) — выделенная нода фиксированной мощности оплачивается помесячно. Понятнее для пользователя, предсказуемый revenue для провайдера. Минус: пользователь переплачивает при низкой нагрузке.

Hybrid — базовый план с месячным включённым объёмом, overage billing сверху. Используют большинство зрелых провайдеров.

Как устроена архитектура биллинговой системы?

Как организовать слой сбора метрик? — разработка системы биллинга

Критический путь: каждый RPC запрос должен быть залогирован до ответа пользователю — иначе при краше теряем данные об использовании. Допустимый процент потерь (sampling loss) — менее 0.01%. Если теряем больше — backpressure или нода умирает под нагрузкой.

Архитектура:

Client Request ↓
API Gateway (Nginx / Envoy / Kong) ↓
[access log + request metadata]
Billing Proxy (sidecar) — async write to queue ↓
RPC Node Cluster ↓
Response → Client

Billing proxy пишет в Apache Kafka или NATS JetStream — оба дают at-least-once delivery. Синхронная запись в базу на каждый запрос убивает latency (мы добавляем 100–500мс к каждому RPC вызову, что недопустимо). Использование очереди позволяет обрабатывать события в 10 раз быстрее по сравнению с прямой записью в БД.

// Async metric emission — не блокирует запрос
func (b *BillingMiddleware) RecordUsage(ctx context.Context, event UsageEvent) {
    select {
    case b.eventChan <- event:
        // успешно поставлено в буфер
    default:
        // буфер полон — метрика потеряна, логируем как sampling loss
        b.metrics.IncSamplingLoss()
    }
}

Агрегация и rating engine

Raw события из Kafka → rating pipeline → billable records в PostgreSQL. Rating — это применение тарифных правил к raw usage. Для NaaS:

class RatingEngine:
    def rate_event(self, event: UsageEvent, plan: Plan) -> Decimal:
        method_weight = self.compute_unit_table.get(
            event.method, DEFAULT_WEIGHT
        )
        # Применяем тарифный план
        if plan.type == "included_pool":
            remaining = plan.included_units - plan.used_units
            if remaining > 0:
                billable = max(0, method_weight - remaining)
                plan.used_units += method_weight
            else:
                billable = method_weight
        elif plan.type == "pay_per_use":
            billable = method_weight
        return Decimal(billable) * plan.unit_price

Агрегация происходит по временным окнам (5-минутные buckets), финальная запись — в конце расчётного периода. Это создаёт billing lag — пользователь потратил деньги, но видит обновление баланса через 5 минут. Это норма для NaaS.

Хранение данных

Для биллинга PostgreSQL — правильный выбор. Не ClickHouse, не MongoDB. Биллинг требует ACID при списании средств. Схема:

-- Immutable usage log
CREATE TABLE usage_events (
    id BIGSERIAL PRIMARY KEY,
    account_id UUID NOT NULL,
    node_id UUID NOT NULL,
    method VARCHAR(64),
    chain_id INTEGER,
    weight INTEGER,
    occurred_at TIMESTAMPTZ NOT NULL,
    billed_at TIMESTAMPTZ
) PARTITION BY RANGE (occurred_at);

-- Billing periods
CREATE TABLE billing_records (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    account_id UUID NOT NULL,
    period_start TIMESTAMPTZ NOT NULL,
    period_end TIMESTAMPTZ NOT NULL,
    total_units BIGINT,
    total_amount NUMERIC(20, 8),
    currency VARCHAR(10), -- 'USD', 'USDC', 'ETH'
    status VARCHAR(20), -- 'pending', 'invoiced', 'paid', 'overdue'
    created_at TIMESTAMPTZ DEFAULT NOW()
);

usage_events партиционируется по дате — иначе через год таблица перестанет вмещаться в индексы оперативной памяти. Retention policy: raw events хранятся 90 дней, агрегаты — бессрочно.

Как реализовать crypto-native биллинг?

Prepaid баланс в стейблкоинах

Большинство NaaS для Web3 работают в prepaid модели: пользователь пополняет баланс в USDC/USDT, списание происходит с него. Это проще чем подписка через кредитную карту и нет chargeback рисков.

contract NaaSBilling {
    IERC20 public immutable usdc;
    mapping(address => uint256) public balances;
    address public billingOracle; // multisig or oracle service

    event Deposit(address indexed account, uint256 amount);
    event Deduction(address indexed account, uint256 amount, string invoiceId);

    function deposit(uint256 amount) external {
        usdc.transferFrom(msg.sender, address(this), amount);
        balances[msg.sender] += amount;
        emit Deposit(msg.sender, amount);
    }

    // Только billingOracle может списывать
    function deductBalance(
        address account,
        uint256 amount,
        string calldata invoiceId
    ) external onlyBillingOracle {
        require(balances[account] >= amount, "Insufficient balance");
        balances[account] -= amount;
        emit Deduction(account, amount, invoiceId);
    }
}

Важный паттерн: billingOracle — не EOA, а multisig или сервис с HSM. Ключ от оракула компрометируется → все балансы под угрозой.

Автоматическое пополнение

Low balance triggers — пользователь настраивает автопополнение при достижении порога: threshold, refillAmount, sourceWallet, maxMonthlySpend. maxMonthlySpend — обязательная защита от billing runaway. Без неё баглый клиент делает миллион запросов и съедает весь баланс пользователя за час.

Какие алерты и rate limiting нужны?

Rate limiting на уровне API Gateway (не биллинга): 1000 req/sec per API key — стандартный дефолт. Без rate limiting один пользователь с багом может положить ноду для всех.

Billing alerts — нотификации при:

• Баланс упал ниже X% от обычного месячного расхода (например, 80%)
• Резкий spike usage (>3x среднего за последний час)
• Нода недоступна (клиент платит за downtime — это должно компенсироваться SLA кредитами)

SLA credits — автоматическое начисление кредитов при downtime. Считается через uptime probe (внешний сервис мониторинга, не ваш собственный). Self-reported uptime 99.99% не вызывает доверия у корпоративных клиентов.

Какие проблемы биллинга встречаются в production?

За время работы с NaaS биллингом встречали несколько нетривиальных проблем. Рассмотрим три наиболее критичных.

Clock skew между нодами — если billing proxy и нода имеют расхождение часов >1 сек, timestamps в usage events некорректны. NTP обязателен, предпочтительно chrony с Google NTP серверами.

Duplicate events при retry — Kafka at-least-once delivery означает дубликаты при retry. Каждое событие должно иметь idempotency key (request_id + node_id), rating engine де-дуплицирует перед записью.

Timezone bugs в billing cycles — расчётный период "1-е число месяца" в UTC. Пользователь из UTC-8 видит что цикл закрывается в 16:00 его времени. Нужна явная документация и по желанию — кастомные billing cycles.

Сроки разработки полноценной NaaS billing системы: 3–5 месяцев для команды из 2–3 backend инженеров. MVP с prepaid балансом и базовым rate limiting — 6–8 недель.

Что входит в разработку системы биллинга?

• Документация архитектуры и API
• Исходный код с комментариями
• Инструкция по развертыванию (Docker, Kubernetes)
• Обучение команды заказчика
• Техническая поддержка 3 месяца
• Гарантия устранения ошибок

Гарантия точности биллинга: мы гарантируем, что система проходит аудит на предмет утечки средств и корректности расчетов. В течение 3 месяцев после сдачи исправляем любые ошибки бесплатно. Ошибки биллинга могут стоить до 10% выручки провайдера — наша задача свести этот риск к нулю.

Свяжитесь с нами для консультации по архитектуре вашего NaaS биллинга. Закажите разработку системы под ключ и получите оценку проекта.