Tecnologías e Infraestructura → Enfoque y características de Serverless

Enfoque y funciones de Serverless

1) Qué es serverless y cuándo se necesita

Serverless es un modelo donde la nube asume la administración de servidores, escalado y parches, y el comando escribe controladores de eventos y utiliza FaaS (Functions-as-a-Service) y BaaS (servicios managed: colas, DB, repositorios). Usted gana en la velocidad de entrega, paga por la ejecución real y escala fácilmente las cargas «efervescentes».

• Webhooks PSP/KYC (muchas consultas cortas, picos impredecibles).
• Antifraude/scoring (funciones de evento, enrichment, feature store).
• Informes/CDC → DWH (procesamiento por lotes y streaming).
• Marketing/CRM (eventos desencadenantes, cañones, cupones, segmentación).
• Fácil backend-API y tareas de servicio (throttling, cron-functions).

• Se requiere una baja latencia P99 constante (sub-10ms) sin dudar.
• Conexiones/protocolos de larga vida (tiempo real de alta frecuencia sin proxy).
• Grandes, computación stateful con CPU/GPU de larga duración y tight coupling.

2) Ladrillos arquitectónicos

2. 1 FaaS

Controladores de eventos: puerta de enlace HTTP/API, colas, streams, temporizadores, almacenamiento de objetos, disparadores de BD.
Inicio/empaquetado fino: capas/imagen-función, calentamiento.

2. 2 BaaS e integraciones

Colas/streaming (at-least-once), Pub/Sub para eventos de dominio.
Almacenamiento: objeto (materia prima/artefactos), KV/caché, documentos/relacion.
Orquestación: state machines/step functions, sagas y compensaciones.
Puerta de enlace API: autenticación (OAuth/OIDC/HMAC), límites, transformaciones.

2. 3 Bucle de red

Frente público (edge/API-gateway) + características privadas en VPC para acceder a DB/secretos/PSP.
Control egress: allow-list a PSP/KYC, NAT-IP fijo.

3) Rendimiento: inicio en frío, competitividad, duración

Inicio en frío: primera función de inicio del contenedor después del tiempo de inactividad.
Mitigar: minimizar las adicciones, utilizar el «calentamiento» (invoke periodic), mantener las funciones en la misma zona que las fuentes, aplicar timeouts largos con cuidado.
Competitividad: defina 'max _ concurrency' y límites en el origen (colas/gateway) para no «rellenar» el PSP/DB.
Duración de la ejecución: para tareas largas - desglose por pasos + orquestación (step functions), para cálculos pesados - batch/containers.

4) Fiabilidad: idempotencia, retraídas, DLQ

Idempotencia: 'Idempotency-Key '/deduplicación en recepción (clave + almacenamiento TTL).
Retraídas: retroceso exponencial + jitter, límites de intento; separar los errores empresariales (4xx) de los temporales (5xx/timeout).
DLQ (dead-letter queue): para los mensajes que no han pasado después de N intentos; la consola de replay y el rastreo son obligatorios.
Exactly-once (prácticamente): plantillas de outbox/inbox, registro transaccional de eventos.

5) Estado y orquestación

Sin estado en la función, el estado es en almacenamiento externo.
Máquinas de estado: pasos de pago/retiro, KYC-workflow, comprobación antifraude; un modelo claro de errores/compensaciones.
Sagi: «reservar → confirmar → compensar» al retroceder.

6) Seguridad y cumplimiento

IAM por el principio de los privilegios más pequeños: roles por función, scoping por cola/baquetas/tabla.
Secretos: gestor de secretos/KMS, rotación, nivel HSM para claves.
mTLS/HMAC para webhooks, firma corporal, ventana de tiempo ± 5 min.
Protección WAF/bot integrada en la puerta de enlace API, rate-limits/quotas.
Segmentación: prod/stage, cuentas de servicio, sabsets privados.
PII/PCI: tokenización PAN, enmascaramiento de registros, «minimización de datos».
Auditoría: registros inmutables (WORM), seguimiento de llamadas, almacenamiento de información de regulación.

7) Observabilidad y control de calidad

Métricas: RPS, P50/P95/P99, errores de código, duración, arranque en frío, transportador retraído, tamaño DLQ.
Treking (OTel): correlación de 'trace _ id' a través de la puerta de enlace → la función de cola → → DAB/PSP; etiquetas obligatorias 'api _ version', 'region', 'partner'.
Registros: estructurados, con camuflaje PII.
Alertas por síntomas: burn-rate SLO, crecimiento retraído, cola P99.
Sintética: inspecciones de los países objetivo (TR/BR/EU), simulación de webhooks.

8) FinOps y costo

Pague «por llamadas y milisegundos». Seguimiento: frecuencia de lanzamiento, duración, memoria, tráfico.
Perfila las vías de acceso: lleva las dependencias pesadas a la capa/imagen, almacena en caché las conexiones.
Contenga el fan out (llamadas paralelas masivas) con límites y batcheo.
Reconocer «fugas»: retraídas infinitas, mensajes en DLQ sin procesar.
Planifique ventanas de pico (torneos/eventos) - calentamiento predictivo y cupos.

9) CI/CD y control de versiones

IAc: Terraform/CloudFormation/SAM/CDK: plantillas de funciones, colas, derechos, gateways.
Empaquetado: archivos de dependencia de bloqueo, imagen/capas mínimas.
Pruebas: pruebas de contrato (OpenAPI/gRPC), integraciones con rantime local, pruebas de idempotencia.
Deploy: canary/blue-green, feature flags, rollback rápido.
Versionar API: '/vN/' o mediatipos; Deprecation/Sunset y compatibilidad de esquemas de eventos.

10) Patrones para iGaming/Fintech

Webhooks de pagos/conclusiones: recepción → validación de firma → idempotencia → publicación del evento 'payout. updated '→ orquestación de actualizaciones de monedero/informes.
Puntuación antifraude: función-enricher (IP/device/geo/historia), solución asíncrona, timeouts y estrategias fallback.
KYC/AML pipeline: verificaciones paralelas (documentos, sanciones, PEP), agregación de resultados, sagas para solicitudes repetidas.
Torneos/clasificaciones: eventos de rondas → agregación streaming → actualización de tablas de clasificación, caché TTL para lectura.
Informes a reguladores: CDC → funciones de transformación → escaparate en DWH, SLA sobre la frescura de los datos.
Marketing/CRM: desencadenantes de comportamiento → cupones/cañones, deduplicación y límites por usuario.

11) Ejemplos de fragmentos

11. 1 Recepción idempotente del webhook (pseudocódigo)

python def handler(event):
assert verify_hmac(event. headers, event. body, secret)
key = f"idemp:{event. headers['Idempotency-Key']}"
if kv. exists(key):
return kv. get (key) # repeat - give the same result result = process (event. body) # public event, state record kv. set(key, result, ttl=86400)
return result

11. 2 Orquestación de retiro de fondos (máquina de estado, idea)

1. 'validate _ request' → 2) 'lock _ balance' → 3) 'call _ psp' (con retrés) →

2. 'await _ webhook' (timaut → compensación) → 5) 'finalize/notify'.

12) Lista de comprobación de implementación serverless

1. Se han identificado las fuentes de los acontecimientos y los arreglos contractuales (diagramas/versiones).
2. Se han configurado límites de competencia y retrés «cuidadosos», hay DLQ y replay.
3. Se incluyen redes privadas/VPC, lista egress-allow, IP fija a PSP.
4. IAM por el principio de los privilegios más pequeños, secretos en KMS/Secret Manager.
5. Observabilidad: seguimiento de OTel, dashboards por P99/errores/arranque en frío.
6. FinOps: presupuestos, alertas de costo, control de duración/memoria.
7. CI/CD: canario/azul-verde, autovías de contratos/idempotencia.
8. Documentación: DevPortal/colección Postman, ejemplos de payload's, Deprecation/Sunset.

13) Anti-patrones

Funciones «gruesas» con un montón de dependencias → lentos inicios en frío.
Falta de idempotencia y firma de webhooks → duplicados/fraudes.
Fan Out sin límites → tormenta de competencia, trotando con el proveedor.
La lógica en temporizadores/coronas sin rastreo/alertas → fallas SLA «silenciosas».
Mezclar secretos prod en variables de entorno sin cifrado.
Contratos de eventos sin Schema Registry y reglas de interoperabilidad.

14) Resultado

Serverless es un sistema operativo cloud de eventos: se centra en la lógica empresarial y la escala y la infraestructura son «bajo demanda». Conecte los servicios administrados FaaS +, agregue idempotencia, orquestación y observabilidad, discipline el costo - y obtenga una plataforma que aguante los picos, evolucione rápidamente y siga siendo económica.