Płynność zbiorowa
1) Dlaczego go potrzebujesz
Natychmiastowa płynność w nowych klastrach. Uruchomienie w regionie/niszy - „wymieszać” basen ogólny.
Lepsze dopasowanie i ceny. Głęboki rynek → mniej rozłożone, powyżej EPI (poprawa w efektywnej cenie/selekcji).
Wstrząsy podaży/popytu. Przepływ obciążenia między węzłami zmniejsza awarię i kolejki.
Ekonomia. Powyżej wskaźnika napełniania i ARPU z umiarkowanym wzrostem kosztów; możliwość sprzedaży krzyżowej.
2) Zbiorowe modele płynności
3) Elementy architektoniczne
Orderbook/catalog: aplikacja/oferta abstrakcji, status i wersje, SLA i atrybuty kompatybilności.
SOR (Smart Order Routing): zasady wyboru puli/dostawcy z uwzględnieniem ceny/jakości/jurysdykcji/opóźnienia.
Spójność: dzienniki CDC i zdarzeń, event _ id dedup, transakcje kompensacyjne.
Przypisanie i rozliczenie: kto jest „właścicielem” transakcji/prowizji, żądanie okien, uzgodnienie.
Jakość i reputacja: oceny partnerów/SLA, kary, odznaki.
Prywatność i lokalizacja: maskowanie PD, geosiatka, zasady eksportu zdarzeń.
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) Umowy o dane (minimalne pola)
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: zasady i pseudokoda
Kryteria rankingowe:- 'wynik = 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)Sprawiedliwość: rotacja dostawców, kwoty udziału w obrotach, zerwanie z reputacją i ostatnie wygrane.
6) Wskaźniki płynności
Szybkość wypełniania = zamknięte aplikacje/wszystkie aplikacje (według segmentu/klastra).
Czas do dopasowania (p50/p95) - czas do wyboru/wykonania.
Głębokość - dostępna objętość w określonym przedziale cenowym/jakościowym.
Spread/EPI - poprawa efektywnego wskaźnika cen vs.
Wykorzystanie - wczytanie zdania (bezczynność% - dobra, jeśli bez awarii SLA).
Integralność - odsetek anulowania/konwersji fałdów, rozbieżności w pojednaniu (<).
Sprawiedliwość - zróżnicowanie dystrybucji sprzedaży dostawcom o jednakowej jakości.
- 'fill _ rate _ month ≥ 92%' w klastrze z aktywnymi ofertami ≥ N.
- 'p95 _ time _ to _ match ≤ 3s' w godzinach szczytu.
- 'cancel _ rate ≤ 1. 5% "z dostawcą SLA" na czas ≥ 98% ".
7) Obserwowalność i podstawa dowodowa
Zdarzenia: "żądanie. wysłane „,” cytat. otrzymał ',' mecz. made ',' settled ',' cancelled ',' refund '.
Ślady: 'trace _ id' przez SOR → pool → dostawca.
Audyt: podpisy haków internetowych, dziennik wersji książek porządkowych, „zrzut ekranu” cytatów.
Pojednanie: raporty dwustronne, dedup, rozbieżności <, roszczenia o zamknięcie SLA.
8) Prywatność, zgodność, suwerenność
Geosiatka: kategorie wrażliwe/PII nie opuszczają dozwolonego regionu.
Pseudonimizacja: dla wymiany między partnerami - tylko pseudo-identyfikatory.
Zatrzymanie jako kod: zdarzenia TTL, prawo do usunięcia, blokada prawna.
DPA/webhaki: podpis, anty-replay, schemat sterowania.
9) Model operacyjny i obliczenia
Role: Operator rynku (ty), Baseny/Partnerzy (podaż), Kanały/Prezentacje (popyt).
Handel: RevShare/CPA/gwarancje minimalne; „klip” do routingu/poprawy cen.
Kredyty/kary: za zakłócenia SLA, fałszywe oferty, niespójność raportów.
Rozrachunek: częstotliwość T + N, ładunki, obciążenia zwrotne, raportowanie.
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) Wzorce integracji
Pull-quote API z time-box (idempotence-key).
Podpisał Webhooks na mecz. made '/' settled '(retrai z wykładnikiem).
Autobus imprezowy do orderu CDC i analityki (wersje wydarzeń).
Seria-recon (dziennie SFTP/Blob + checksums).
Skrzynka odbiorcza/skrzynka odbiorcza po obu stronach + dedup.
Schemat/SDK wersioning, okno kompatybilności.
11) Kontrola przeciążenia i huśtawki
Anty-congestie: ograniczenia, kolejki, priorytety VIP/złożonych przypadków, czynniki przepięcia.
Anty-arbitraż (toksyczny): zakazy „samodzielnej realizacji” w niskiej cenie/jakości, monitorowanie wniosków „ping-pong”.
Przeciwdziałanie oszustwom: podpisy urządzeniowe/behawioralne, żetony miodowe, opóźnione kwalifikacje (cool-off).
Degradacja z honorem: upadek na lokalny basen, „najlepszy wysiłek” z przezroczystą degradacją.
12) Przykłady logiki (szkice)
12. 1 Routing jurysdykcyjny i 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 Polityka wymiaru sprawiedliwości (Rego-idea)
rego package fairness deny["overexposed vendor"] {
usage. share[input. vendor] > 0. 45 input. vendor. tier == "silver"
}12. 3 Test konwergencji książki orderowej
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) Wskaźniki zapadalności
Zasięg: udział segmentów/regionów, w których istnieją aktywne oferty ≥ X.
Elastyczność: jak szybko szybkość napełniania regeneruje się przy popycie + WG.
EPI/Spread-improvement: benefit from aggregation vs solo pool.
Sprawiedliwy podział: odchylenie udziału w obrotach od oczekiwanego pod względem jakości.
Recon-health: częstotliwość/czas zamknięcia rozbieżności.
Ocena prywatności: udział tras bez usunięcia PD poza granicami polityki.
14) Anty-wzory
Naga federacja bez SOR i zasad jakości → rozdrobnienie, anulowanie.
„Rynek szkła”: otworzyć wszystko dla wszystkich - splash oszustwa i wojny cenowej.
Brak przypisania i pojednania → wieczne spory i zamrożone płatności.
Twarda synchronia pomiędzy basenami → kaskadowe opóźnienia/awarie.
Te same zasady dla różnych segmentów → degradacja doświadczenia w premium/lokalne nisze.
Ignorowanie TTL oferuje → oferty w „zgniłe” warunki.
Pojedynczy klucz szyfrujący dla całego → rynku nie może być „kasowany” punkt po punkcie.
15) Lista kontrolna architekta
1. Model (wspólna pula/federacja/ośrodek) i zdefiniowane ograniczenia suwerenności?
2. Czy istnieje umowa o dane (schematy, wersje, TTL, podpisy) i okno zgodności?
3. Wdrożony SOR z uczciwością i kompami, płynność SLO i deski rozdzielcze?
4. Rozliczenie/przypisanie, okna reklamacyjne, kredyty/grzywny są zarejestrowane?
5. Zbudowany w trybie anty-congestie/anti-fraud/anti-arbitrage i degradation?
6. Pojednanie i artefakty „dowodu umowy” ustalone?
7. Prywatność: pseudonimizacja, geosiatka, retencja, prawo do usunięcia?
8. Wiertło: Popyt na szczyty naprężeń/kropla basenu/Orderbook Out of Sync?
9. FinOps: budżet wyjścia, koszt trasy, docelowy EPI?
10. Zarządzanie: akcje progowe, certyfikacja partnerów, audyt.
Wniosek
Płynność zbiorowa nie polega na "połączeniu innego partnera", lecz na projektowaniu rynku: jednolitych umów i wydarzeń, przejrzystych zasad trasowania i uczciwości, silnej obserwacji i obliczeń, prywatności i jurysdykcji ", takich jak kod. - Tak więc z różnych źródeł rodzi się jedna, głęboka i zrównoważona pula podaży i popytu - z najlepszym doświadczeniem dla użytkowników i przewidywalną gospodarką dla całego ekosystemu.