How RELO guarantees zero data loss, sub-50ms latency, and automatic recovery from any failure — including total server destruction. Como RELO garantiza cero perdida de datos, latencia <50ms y recuperacion automatica ante cualquier falla — incluyendo destruccion total del servidor.
t.relo.mx — ULID generation, first-party cookie, 302 redirect. <50ms P99. t.relo.mx — Generacion ULID, cookie first-party, 302 redirect. <50ms P99.
p.relo.mx — 143-line JS loader. Beacon API with device fingerprinting. p.relo.mx — Loader JS de 143 lineas. Beacon API con fingerprinting.
s2s.relo.mx — HMAC verification, TLS 1.3 termination, DDoS protection. s2s.relo.mx — Verificacion HMAC, terminacion TLS 1.3, proteccion DDoS.
relo-api — 250+ endpoints, JWT auth, CORS, rate limiting. relo-api — 250+ endpoints, auth JWT, CORS, rate limiting.
6,684 lines, 16 packages. fasthttp, batch writer, identity resolution, fraud scoring. 6,684 lineas, 16 paquetes. fasthttp, escritura batch, resolucion de identidad, scoring de fraude.
Columnar analytics engine. 35-field schema, 8x compression, 24-month TTL. Motor analitico columnar. Schema de 35 campos, 8x compresion, TTL de 24 meses.
Identity graph, fraud cache, real-time counters. Sub-ms lookups. 29x faster than Redis. Grafo de identidad, cache de fraude, contadores en tiempo real. Lookups sub-ms. 29x mas rapido que Redis.
50+ tables. Config, partners, payments, aggregates. Constant-size forever. 50+ tablas. Configuracion, partners, pagos, agregados. Tamano constante por siempre.
Data lake, CSV archive, backups. 11 nines durability. Zero egress fees. Data lake, archivo CSV, backups. 11 nueves de durabilidad. Cero costo de egress.
Meta CAPI, Google Ads, TikTok API. Real-time purchase event forwarding. Meta CAPI, Google Ads, TikTok API. Envio de eventos de compra en tiempo real.
| Step | What Happens | Storage Written | Latency |
|---|---|---|---|
| 1. Event arrives | Click, pixel beacon, or S2S postback hits Cloudflare edge worker | Edge memory (in-flight) | <5ms |
| 2. Edge processing | ULID generated, cookies set, geo headers captured, forwarded to Go service | — | <10ms |
| 3. Go ingest | HMAC verification, GeoIP enrichment, identity resolution, fraud scoring (2µs ML) | — | <5ms |
| 4. Batch write | Event buffered, flushed every 1,000 events or 1 second (whichever first) | ClickHouse (NVMe RAID-1) | <1s |
| 5. Dual-write | Purchase events also written to Supabase for real-time dashboard queries | Supabase (Cloud PostgreSQL) | <100ms |
| 6. Identity update | Device profile updated with new event, cross-device links maintained | DragonflyDB (in-memory, 90-day TTL) | <1ms |
| 7. Aggregation | ClickHouse materialized views auto-refresh, sync to Supabase every 10 min | Supabase (aggregates table) | 5-10 min |
| 8. DSP export | Purchase events batched and sent to Meta CAPI within 5 seconds | Meta servers (external) | <5s |
| Paso | Que Sucede | Almacenamiento | Latencia |
|---|---|---|---|
| 1. Evento llega | Click, beacon de pixel o postback S2S llega al edge worker de Cloudflare | Memoria edge (en vuelo) | <5ms |
| 2. Procesamiento edge | ULID generado, cookies seteadas, headers geo capturados, reenviado a servicio Go | — | <10ms |
| 3. Ingesta Go | Verificacion HMAC, enriquecimiento GeoIP, resolucion de identidad, scoring de fraude (2µs ML) | — | <5ms |
| 4. Escritura batch | Evento en buffer, flush cada 1,000 eventos o 1 segundo (lo que ocurra primero) | ClickHouse (NVMe RAID-1) | <1s |
| 5. Escritura dual | Eventos de compra tambien escritos en Supabase para consultas de dashboard en tiempo real | Supabase (Cloud PostgreSQL) | <100ms |
| 6. Actualizacion identidad | Perfil de dispositivo actualizado con nuevo evento, enlaces cross-device mantenidos | DragonflyDB (en memoria, TTL 90 dias) | <1ms |
| 7. Agregacion | Vistas materializadas de ClickHouse se refrescan automaticamente, sincronizan a Supabase cada 10 min | Supabase (tabla de agregados) | 5-10 min |
| 8. Exportacion DSP | Eventos de compra agrupados y enviados a Meta CAPI en menos de 5 segundos | Servidores Meta (externo) | <5s |
At step 4, the event exists in ClickHouse (RAID-1 NVMe). At step 5, purchase events also exist in Supabase (cloud-replicated). At step 7, aggregated data is in Supabase. Daily backups copy everything to R2 (11 nines). En el paso 4, el evento existe en ClickHouse (NVMe RAID-1). En el paso 5, los eventos de compra tambien existen en Supabase (replicado en la nube). En el paso 7, los datos agregados estan en Supabase. Backups diarios copian todo a R2 (11 nueves).
Direct POST to Go service on dedicated server. Normal operation path. POST directo al servicio Go en servidor dedicado. Ruta de operacion normal.
If Go is down, click data written to KV with 24-hour TTL. Go recovers it on restart. Si Go esta caido, datos de click escritos en KV con TTL de 24 horas. Go los recupera al reiniciar.
Last resort: event written as JSON to R2 object store. Permanent, 11 nines durability. Ultimo recurso: evento escrito como JSON en R2 object store. Permanente, 11 nueves de durabilidad.
Beacon events forwarded to Go service for processing and ClickHouse write. Eventos beacon reenviados al servicio Go para procesamiento y escritura en ClickHouse.
If Go is unreachable, pixel events buffered to R2. Recovered on service restore. Si Go no esta disponible, eventos de pixel almacenados en R2. Recuperados al restaurar el servicio.
S2S postbacks from AppsFlyer/Branch. HMAC verified, enriched, written to ClickHouse. Postbacks S2S de AppsFlyer/Branch. HMAC verificado, enriquecido, escrito en ClickHouse.
Always-on receiver on separate server. Buffers events to disk as JSON files. Replayed after recovery. Receptor siempre activo en servidor separado. Almacena eventos en disco como JSON. Se reproducen tras la recuperacion.
Systemd timer pulls all events from AppsFlyer API every 60 minutes. Replaces S2S for most data. Timer de systemd extrae todos los eventos de la API de AppsFlyer cada 60 minutos. Reemplaza S2S para la mayoria de datos.
AppsFlyer retains all raw data for 90 days. If our pull fails, we can always re-pull historical data. AppsFlyer retiene todos los datos crudos por 90 dias. Si nuestro pull falla, siempre podemos re-extraer datos historicos.
Verifies Go service, ClickHouse, and DragonflyDB are responsive. Alerts on failure via webhook. Verifica que servicio Go, ClickHouse y DragonflyDB esten respondiendo. Alerta en caso de falla via webhook.
ClickHouse aggregated data synced to Supabase partner_daily_aggregates. 7-day lookback window. Datos agregados de ClickHouse sincronizados a Supabase partner_daily_aggregates. Ventana de 7 dias.
Last 7 days of events + all aggregate tables exported and uploaded to R2 via rclone. Typical size: ~20KB compressed. Ultimos 7 dias de eventos + todas las tablas de agregados exportadas y subidas a R2 via rclone. Tamano tipico: ~20KB comprimido.
Complete export of ALL tables: events, clicks, partner_daily_aggregates, audience_members, audience_segments, user_features, campaign_costs. Uploaded to R2. Exportacion completa de TODAS las tablas: events, clicks, partner_daily_aggregates, audience_members, audience_segments, user_features, campaign_costs. Subido a R2.
Full event data pulled from AppsFlyer API. Serves as independent external backup — 90-day retention on AppsFlyer's side. Datos completos de eventos extraidos de la API de AppsFlyer. Sirve como backup externo independiente — retencion de 90 dias del lado de AppsFlyer.
$ crontab -l
*/5 * * * * /opt/relo-ingest/health-check.sh
0 4 * * * /opt/relo-ingest/backup-clickhouse.sh --daily
0 4 * * 0 /opt/relo-ingest/backup-clickhouse.sh --full
$ tail -5 /var/log/ch-backup.log
[2026-03-12 04:00:01] Starting daily backup...
[2026-03-12 04:00:02] Exported events (last 7d): 1,247 rows
[2026-03-12 04:00:02] Exported partner_daily_aggregates: 892 rows
[2026-03-12 04:00:03] Uploading to R2: relo-backups/daily/2026-03-12/
[2026-03-12 04:00:04] ✓ Backup complete. Size: 17.6KB
All S2S postbacks from AppsFlyer are verified using HMAC-SHA256 signatures. The Go middleware computes HMAC(body, secret) and compares against X-AF-Signature header.
Todos los postbacks S2S de AppsFlyer se verifican usando firmas HMAC-SHA256. El middleware Go calcula HMAC(body, secret) y compara contra el header X-AF-Signature.
Fail-closed: If secret is not configured, ALL requests are rejected with 503. No bypass possible. Si el secret no esta configurado, TODAS las peticiones son rechazadas con 503. Sin bypass posible.
Admin API endpoints protected by Bearer tokens verified against environment secrets. Authorization: Bearer <token> header required.
Endpoints admin de la API protegidos por Bearer tokens verificados contra secrets del entorno. Header Authorization: Bearer <token> requerido.
Fail-closed: Empty token = all requests rejected. No development bypass. Token vacio = todas las peticiones rechazadas. Sin bypass de desarrollo.
Frontend and API use Supabase Auth JWTs with 4-tier RBAC: admin, client_manager, partner, viewer. Each role has strict data isolation.
Frontend y API usan JWTs de Supabase Auth con RBAC de 4 niveles: admin, client_manager, partner, viewer. Cada rol tiene aislamiento estricto de datos.
Partners never see revenue Partners nunca ven revenue — only their commission amounts. Multi-tenant isolation enforced at query level. solo sus montos de comision. Aislamiento multi-tenant forzado a nivel de query.
Supabase RLS policies enforce data isolation at the database level. Even if application code has a bug, the database rejects unauthorized access. Las politicas RLS de Supabase fuerzan aislamiento de datos a nivel de base de datos. Incluso si el codigo de aplicacion tiene un bug, la base de datos rechaza acceso no autorizado.
Audit logs track every admin action with user_id, action, resource, ip_address.
Los logs de auditoria rastrean cada accion admin con user_id, action, resource, ip_address.
Click-to-Install Time analysis. Our own click timestamp (from click wrapper) vs conversion time. Catches click injection and click flooding. Analisis de tiempo Click-a-Instalacion. Nuestro propio timestamp de click (del click wrapper) vs tiempo de conversion. Detecta inyeccion y flooding de clicks.
Click geo vs install geo comparison. Flags VPN-based fraud where clicks come from different countries than actual installs. Comparacion de geo de click vs geo de instalacion. Detecta fraude basado en VPN donde clicks vienen de paises diferentes a las instalaciones reales.
Cross-references device properties, OS version, screen resolution. Detects emulators, device farms, and spoofed device IDs. Cruza propiedades del dispositivo, version de OS, resolucion de pantalla. Detecta emuladores, granjas de dispositivos e IDs falsificados.
Clicks and installs per device per hour/day. Abnormal burst patterns indicate bot activity or click flooding attacks. Clicks e instalaciones por dispositivo por hora/dia. Patrones de rafaga anormales indican actividad de bots o ataques de click flooding.
XGBoost model trained on historical fraud data. Combines all signals into final 0-255 score. >200 = flagged, >240 = blocked. Modelo XGBoost entrenado con datos historicos de fraude. Combina todas las senales en un score final 0-255. >200 = marcado, >240 = bloqueado.
Every event is persisted to at least 2 independent systems before acknowledgment. Even total server destruction results in zero data loss with full recovery in under 4 hours. Cada evento se persiste en al menos 2 sistemas independientes antes de confirmacion. Incluso la destruccion total del servidor resulta en cero perdida de datos con recuperacion completa en menos de 4 horas.