Колективна ліквідність
1) Навіщо це потрібно
Миттєва ліквідність у нових кластерах. Запускаєтеся в регіоні/ніші - «підмішуєте» загальний пул.
Краща відповідність і ціни. Глибокий ринок → менше «спред», вище EPI (поліпшення ефективної ціни/підбору).
Шоки попиту/пропозиції. Перетікання навантаження між вузлами знижує відмову і черги.
Економіка. Вище fill rate і ARPU при помірному зростанні витрат; можливість cross-sell.
2) Моделі колективної ліквідності
3) Архітектурні компоненти
Ордербук/каталог: абстракції заявка/оффер, статус і версії, SLAs і атрибути сумісності.
SOR (Smart Order Routing): правила вибору пулу/постачальника з урахуванням ціни/якості/юрисдикції/латентності.
Узгодженість: CDC і журнали подій, дедуп по'event _ id', компенсують транзакції.
Атрибуція та білінг: хто «власника» угоди/комісії, вікна претензій, reconciliation.
Якість і репутація: рейтинги/SLA партнера, штрафи, бейджі.
Приватність і локалізація: маскування ПД, гео-пінінг, правила експорту подій.
mermaid flowchart LR
U [Demand] --> GW [Routing Gateway]
P1 [Pool A] --- GW
P2 [Pool B] --- GW
P3 [Partner C] --- GW
GW --> SB[Settlement/Billing]
GW --> OBS[Observability/SLO]4) Контракти даних (мінімум полів)
yaml offer. v1:
id: uuid kind: product slot capacity price: {amount: decimal, currency: ISO4217}
quality: {rating: 0..5, sla_ttm_ms: int}
geo: {region: "EU", city: "Tallinn"}
vendor: {id: "partner-123", tier: "gold"}
terms: {ttl_s: 60, cancellation: "window:15m"}
version: 7 request. v1:
id: uuid constraints: {geo, time, price_ceiling, compliance}
qos: {max_ttm_ms: 500, min_rating: 4. 0}
trace_id: uuid consent: {...}5) SOR: Правила та псевдокод
Критерії ранжування:- `score = w_priceprice_improvement + w_slattm_slo + w_qquality + w_geodistance_penalty + w_riskvendor_risk_penalty`
python def route(request, pools):
candidates = []
for pool in pools:
if not compliant(request, pool):
continue quotes = pool. quote (request) # timebox, idempotent for q in quotes:
s = score(q, request)
candidates. append((s, pool, q))
ordered = sorted(candidates, key=lambda x: -x[0])
return best_feasible(ordered, fairness=request. fairness)Fairness (справедливість): ротація постачальників, квоти на частку обороту, tie-break по репутації і недавнім виграшам.
6) Метрики ліквідності
Fill rate = закриті заявки/всі заявки (по сегменту/кластеру).
Time-to-match (p50/p95) - час до підбору/виконання.
Depth - доступний обсяг в заданому діапазоні ціни/якості.
Spread/EPI - поліпшення ефективної ціни vs бенчмарка.
Utilization - завантаження пропозиції (idle% ↓ - добре, якщо без SLA-провалів).
Integrity - частка відмін/фолс-конверсій, розбіжність в reconciliation (<ε).
Fairness - дисперсія розподілу обороту по постачальниках при рівній якості.
- 'fill _ rate _ month ≥ 92%'в кластері з ≥ N активними оферами.
- 'p95 _ time _ to _ match ≤ 3s'в піковий годинник.
- `cancel_rate ≤ 1. 5%'при SLA постачальника'on-time ≥ 98%'.
7) Спостережуваність і доказова база
Події: `request. sent`, `quote. received`, `match. made`, `settled`, `cancelled`, `refund`.
Трасування: 'trace _ id'наскрізний через SOR → пул → постачальник.
Аудит: підписи вебхуків, журнал версій ордербука, «скріншот» котирувань.
Reconciliation: двосторонні звіти, дедуп, розбіжності <ε, SLA закриття претензій.
8) Приватність, комплаєнс, суверенітет
Geo-pinning: чутливі категорії/PII не виходять з дозволеного регіону.
Псевдонімізація: для міжпартнерського обміну - тільки псевдо-ідентифікатори.
Retention як код: TTL подій, право на видалення, Legal Hold.
DPA/вебхуки: підпис, анти-replay, контроль схем.
9) Операційна модель і розрахунки
Ролі: Market Operator (ви), Пули/Партнери (supply), Канали/Вітрини (demand).
Комерція: RevShare/CPA/мінімальні гарантії; «кліп» за маршрутизацію/поліпшення ціни.
Кредити/штрафи: за зрив SLA, помилкові оффери, неузгодженість звітів.
Settlement: періодичність T + N, утримання, chargebacks, звітність.
yaml partner_id: "pool-A"
sla:
fill_rate: ">= 90%"
on_time: ">= 98%"
quote_ttl_s: 2 limits:
rps: 200 region: ["EU","TR"]
commercials:
model: "revshare: 20% of net"
security:
webhook_signature: "Ed25519"10) Патерни інтеграції
Pull-quote API з тайм-боксом (idempotency-key).
Підписані Webhooks для'match. made '/' settled'( ретраї з експонентою).
Event bus для CDC ордербука і аналітики (версії подій).
Batch-recon (щоденний SFTP/Blob + контрольні суми).
Outbox/Inbox у обох сторін + дедуп.
Версіонування схем/SDK, вікно сумісності.
11) Управління перевантаженням і гойдалками
Анти-конгестія: лімітери, черги, пріоритизація VIP/складних кейсів, surge-коефіцієнти.
Анти-арбітраж (токсичний): заборони «самовиконань» за заниженою ціною/якістю, моніторинг «ping-pong» запитів.
Анти-фрод: device/поведінкові сигнатури, honey-tokens, відкладена кваліфікація (cool-off).
Деградація з честю: fallback на локальний пул, «best-effort» з прозорим погіршенням.
12) Приклади логіки (скетчі)
12. 1 Роутинг з урахуванням юрисдикції і SLO
python def compliant(req, pool):
return (req. constraints. geo in pool. regions and pool. sla. quote_ttl_s <= 2 and pool. vendor_tier in {"gold","silver"})12. 2 Політика справедливості (Rego-ідея)
rego package fairness deny["overexposed vendor"] {
usage. share[input. vendor] > 0. 45 input. vendor. tier == "silver"
}12. 3 Проба конвергенції ордербука
sql
SELECT offer_id, MAX(version)-MIN(version) AS drift
FROM orderbook_events
WHERE ts >= now() - interval '5 minutes'
GROUP BY 1
HAVING MAX(version)-MIN(version) > 1; -- fragmentation signal13) Метрики зрілості
Coverage: частка сегментів/регіонів, де є ≥ X активних офферів.
Elasticity: як швидко fill rate відновлюється при + Δ попиту.
EPI/Spread-improvement: вигода від агрегації vs соло-пул.
Fair-distribution: відхилення частки обороту від очікуваної за якістю.
Recon-health: частота/термін закриття розбіжностей.
Privacy-score: частка маршрутів без виносу ПД за межі політики.
14) Анти-патерни
Гола федерація без SOR і правил якості → фрагментація, відміни.
«Скляний ринок»: відкриваєте все всім - сплеск фроду і цінової війни.
Немає атрибуції і reconciliation → вічні суперечки і заморожені виплати.
Жорстка синхронщина між пулами → каскадна латентність/відмови.
Однакові правила для різних сегментів → деградація досвіду в преміум/локальних нішах.
Ігнорування TTL офферів → угоди по «протухлим» умовам.
Єдиний ключ шифрування на весь ринок → неможливо точково «стерти» дані.
15) Чек-лист архітектора
1. Визначено модель (загальний пул/федерація/хаб) та обмеження суверенітету?
2. Є контракт даних (схеми, версії, TTL, підписи) і вікно сумісності?
3. Реалізований SOR з fairness і бекомпамі, SLO ліквідності і дашбордами?
4. Прописані білінг/атрибуція, вікна претензій, кредити/штрафи?
5. Вбудовані анти-конгестія/анти-фрод/анти-арбітраж і режим деградації?
6. Налагоджений reconciliation і артефакти «докази угоди»?
7. Приватність: псевдонімізація, geo-pinning, ретеншен, право на видалення?
8. Навчання: стрес-піки попиту/падіння пулу/розсинхронізація ордербука?
9. FinOps: бюджет egress, вартість маршрутизації, цільовий EPI?
10. Governance: порогові частки, сертифікація партнерів, аудит.
Висновок
Колективна ліквідність - це не «підключити ще одного партнера», а спроектувати ринок: єдині контракти і події, прозорі правила маршрутизації і справедливості, сильна спостережуваність і розрахунки, приватність і юрисдикції «як код». Так з розрізнених джерел народжується єдиний, глибокий і стійкий басейн попиту і пропозиції - з кращим досвідом для користувачів і передбачуваною економікою для всієї екосистеми.