Розробка системи білінгу 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 білінгу. Замовте розробку системи під ключ та отримайте оцінку проекту.