Ұжымдық өтімділік
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 - тең сапада өнім берушілер бойынша айналымды бөлу дисперсиясы.
- N ≥ белсенді офферлері бар кластердегі 'fill _ rate _ month ≥ 92%.
- '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) Жекешелiк, комплаенс, егемендiк
Geo-pinning: сезімтал санаттар/PII рұқсат етілген аймақтан шықпайды.
Бүркеншік атау: серіктес аралық алмасу үшін - тек бүркеншік сәйкестендіргіштер.
Retention код ретінде: TTL оқиғалар, жою құқығы, Legal Hold.
DPA/вебхактар: қолтаңба, анти-реплай, схемаларды бақылау.
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).
'match үшін Webhooks қол қойған. made '/' settled '(экспонентті ретрайлер).
CDC ордербука және талдау үшін Event bus (оқиғалар нұсқасы).
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. Fairness және бэкомптермен, SLO өтімділігімен және дашбордтармен SOR іске асырылды ма?
4. Биллинг/атрибуция, шағым терезелері, кредиттер/айыппұлдар жазылды ма?
5. Кіріктірілген анти-конгестия/анти-фрод/анти-төрелік және деградация режимі?
6. reconciliation және «мәміле дәлелі» артефактілері жолға қойылды ма?
7. Құпиялылық: псевдонимизация, geo-pinning, ретеншен, жою құқығы?
8. Жаттығулар: сұраныстың стресс-шыңы/пулдың құлдырауы/ордербуктің рассинхронизациясы?
9. FinOps: egress бюджеті, бағыттау құны, мақсатты EPI?
10. Governance: шекті үлестер, серіктестерді сертификаттау, аудит.
Қорытынды
Ұжымдық өтімділік - бұл «тағы бір әріптесті қосу» емес, нарықты жобалау: бірыңғай келісімшарттар мен оқиғалар, маршруттау мен әділеттіліктің ашық ережелері, күшті бақылау мен есептеулер, «код ретінде» құпиялылық пен юрисдикция. Осылайша, шашыраңқы көздерден сұраныс пен ұсыныстың бірыңғай, терең және орнықты бассейні пайда болады - пайдаланушылар үшін үздік тәжірибесі және бүкіл экожүйе үшін болжамды экономикасы бар.