Liquidez coletiva

1) Por que é necessário

Liquidez instantânea nos novos clusters. Execute-se na região/nicho - «afunde» o pool comum.
Melhor alinhamento e preços. O mercado profundo é menor que o «spread», acima do EPI (melhoria do preço efetivo/alíquota).
Choques de oferta/oferta. Arrastar carga entre nós reduz a falha e a fila.
Economia. Acima fill rate e ARPU, com aumento moderado de custos; capacidade cross-sell.

2) Modelos de liquidez coletiva

3) Componentes arquitetônicos

Mandbook/diretório: abstração candidatura/off, status e versões, SLAs e atributos de compatibilidade.
SOR (Smart Order Routing): regras de escolha do pool/fornecedor com base em preço/qualidade/jurisdição/latência.
Coerência: CDC e registros de eventos, dedução por 'event _ id', compensando transações.
Atribuição e billing: quem é o «dono» da transação/comissão, janelas de reclamação, recepção.
Qualidade e reputação: classificações/SLA parceiro, multas, crachás.
Privacidade e localização: camuflagem de PD, geo-pinning, regras de exportação de eventos.

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) Contratos de dados (mínimo de campos)

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: regras e pseudo-código

• `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 (justiça): rotação de fornecedores, quotas de circulação, tie-break de reputação e ganhos recentes.

6) Métricas de liquidez

Fill rate = inscrições fechadas/todos os pedidos (por segmento/cluster).
Time-to-match (p50/p95) - tempo até a seleção/execução.
Depth é um volume disponível em um determinado intervalo de preço/qualidade.
Spread/EPI - melhorar o preço efetivo vs benchmark.
Utilization - Carregar a oferta (idle%) é bom se não houver falhas SLA).
Integrity - proporção de tomates/conversões de fols, divergência de reconciliação.
Fairness - Dispersão de distribuição de circulação por fornecedores com qualidade igual.

• 'fill _ rate _ month ≥ 92%' em um cluster com ≥ N offs ativos.
• 'p95 _ time _ to _ match ≤ 3s' nos horários de pico.
• `cancel_rate ≤ 1. 5% 'com o provedor SLA' on-time ≥ 98% '.

7) Observabilidade e base de provas

Eventos: 'request. sent`, `quote. received`, `match. made`, `settled`, `cancelled`, `refund`.
Traçados: 'trace _ id' por meio do pool SOR provedor.
Auditoria: assinaturas de webhooks, registro de versões do mandado, «ecrã» da cotação.
Reconciação: relatórios bilaterais, dedução, discrepâncias <£, SLA encerramento de reclamações.

8) Privacidade, complacência, soberania

Geo-pinning: categorias sensíveis/PII não saem da região permitida.
Pseudônimo: para intercâmbio entre padrões, apenas pseudo-identificadores.
Retenção como código: TTL eventos, direito de remoção, Legal Hold.
DPA/webhooks: assinatura, anti-replay, controle de circuitos.

9) Modelo operacional e cálculos

Papéis: Market Operator (você), Poulas/Associados (suply), Canais/Vitrines (demand).
Comercial: RevShare/CPA/garantias mínimas; «clipe» por rotação/melhoria de preço.
Créditos/multas: por quebra de SLA, falsos ofícios, incoerência de relatórios.
Senslement: periodicidade T + N, retenção, marcebacks, relatórios.

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) Patrões de integração

Pull-cote API com tempo-boxe (idempotency-key).
Webhooks assinados para 'match. made '/' setled '(retrai com exposição).
Event ônibus para o mandado CDC e analistas (versões de eventos).
Batch-recon (diária SFTP/Blob + valores de controle).
Outbox/Inbox em ambos os lados + deadup.
Versionagem de circuitos/SDK, janela de compatibilidade.

11) Controle de sobrecarga e balanços

Anti-congénere: limitadores, filas, priorização de malas VIP/complexas, coeficientes de surge.
Anti-arbitragem (tóxica): proibições de «auto-cumprimento» por preço/qualidade subestimado, monitoramento de «ping-pong» solicitações.
Anti-frod: device/assinaturas comportamentais, honey-tocens, qualificação adiada (cool-off).
Degradação com honra: fallback para pool local, «best-effort» com piora transparente.

12) Exemplos de lógica (esquetes)

12. 1 Routing com jurisdição e 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 Política de justiça (rego-ideia)

rego package fairness deny["overexposed vendor"] {
usage. share[input. vendor] > 0. 45 input. vendor. tier == "silver"
}

12. 3 Prova de convergência do mandado

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 signal

13) Métricas de maturidade

Coverage: proporção de segmentos/regiões onde há ≥ X off ativos.

Elasticity: A rapidez com que o fill rate se recupera com a demanda +

EPI/Spread-improvement: benefício da agregação vs pool solo.
Fair-distribuição: Desviar a proporção de circulação da qualidade esperada.
Recon-health: frequência/prazo de encerramento de divergências.
Private-Score: Proporção de rotas que não levam o PD para além da política.

14) Anti-pattern

Federação nua sem SOR e regras de qualidade → fragmentação, cancelamento.
«Mercado de Vidro», abrindo tudo para todos, uma subida de frod e guerra de preços.
Não há atribuição e reconciliação → disputa eterna e pagamento congelado.
Sincronia severa entre os pulos → latência em cascata/falhas.
As mesmas regras para diferentes segmentos → a degradação da experiência em nichos premium/local.
Ignorar TTL Offers → transações em termos «oblíquos».
Uma única chave de encriptação para todo o mercado não pode ser «apagada» pontualmente.

15) Folha de cheque do arquiteto

1. São definidos um modelo (pool/federação/hab) e limites de soberania?
2. Há um contrato de dados (esquema, versão, TTL, assinaturas) e uma janela de compatibilidade?
3. Implementado por SOR com fairness e bacombustíveis, SLO liquidez e dashboards?
4. Boletim/atribuição, janelas de reclamação, créditos/multas?
5. Incorporados anti-congestão/anti-frod/anti-arbitragem e regime de degradação?
6. A reconciação e os artefatos «provas da transação» foram instalados?
7. Privacidade: apelido, geo-pinning, retensivo, direito de remoção?
8. Ensinamentos: picos de pressão/queda do pulo/descolonização do mandado?
9. FinOps: orçamento egress, custo de rotação, EPI alvo?
10. Governance: liminares, certificação de parceiros, auditoria.

Conclusão

Liquidez coletiva não é «ligar outro parceiro», mas projetar o mercado: contratos e eventos unificados, regras transparentes de rotação e justiça, forte observabilidade e cálculos, privacidade e jurisdição «como código». Assim, a partir de fontes dispersas, nasce uma bacia de demanda e oferta, profunda e sustentável - com a melhor experiência para os usuários e uma economia previsível para todo o ecossistema.