Sandbox y entornos de prueba

1) Por qué se necesitan contornos dedicados

• verificar rápidamente las hipótesis y la integración sin riesgo para la producción;
• acelerar el ciclo de fidbeck (PR → preview-link en minutos);
• reproducir errores e incidentes en una copia segura;
• realizar pruebas contractuales, de integración, de carga y de caos;
• entrenar a los equipos y poner a los socios en el terreno de juego.

Principios clave: aislamiento, paridad de configuración, determinismo de pruebas, seguridad de datos, observabilidad predeterminada.

2) Jerarquía de entornos y su propósito

Local (Dev) - desarrollo local: Docker Compose/Testcontainers, simuladores de proveedores ligeros.
Sandbox es un stand para integraciones externas (PSP, KYC, agregadores de juegos) con datos falsos y protocolos reales.
QA/Test - pruebas de integración y e2e, fixtures de datos estables, regresiones.
Stage/Pre-Prod es un circuito lo más cercano posible a la producción (configuraciones/límites/topología).
Ephemeral Preview - entorno «en PR» (vive horas/días), recursos autónomos y URL, auto-demolición después de merge/close.

Regla de paridad: "preferencias, políticas y dependencias de infraestructura en Test/Stage ≈ Prod', las diferencias son sólo en secretos y límites.

3) Tipos de sandbox

1. Proveedores de sandbox: PSP/KYC/juegos externos proporcionan pruebas de puntos de vista; agregamos una capa de simuladores para simular casos raros y erróneos (timeouts, 5xx, firmas inestables).
2. Cajas de arena funcionales: instancias autónomas de servicios de dominio (pagos, bonificaciones, aperturas) + fixtures.
3. Sandbox de aprendizaje/demostración: «escaparate» de API para socios con DevPortal, claves, cuotas y límite de tasa.

4) Contratos, simuladores y mocos

Contract-testing (Nat/Buf): el consumidor/proveedor acordará los esquemas; los cambios incompatibles se bloquean en el CI.
Simuladores de proveedores: reproducen casos edge (doble collbacks, deriva de reloj, firma HMAC con timestamp caducado).
Fixtures de eventos (Kafka/NATS): biblioteca de casos 'payment. authorized`, `kyc. verified`, `game. round. settled`.
Inyección de Fault: retardos administrados, drop-rate, mensajes fuera de orden.

X-Timestamp: 1730812800
X-Signature: sha256=hex(hmac_sha256(secret, body + timestamp))

5) Datos de prueba, GDPR/PCI y anonimización

Nunca utilice PII/PAN reales fuera de producción.
Anonimización: generación de sintéticos + tokenización de campos sensibles; listas blancas sólo para cuentas de demostración.
Data factories: fábricas de usuarios/transacciones/sesiones con ID y estados predecibles.
Vistas detallistas: las mismas fixturas entre el paso de las pruebas y los entornos.
Política de retransmisión: auto-limpieza de la vista previa de los alrededores y de la prueba de la DB.

6) Secretos y acceso

Secretos separados los miércoles; créditos temporales y funciones limitadas.
KMS/HSM y rotaciones; secretos excluidos en Git.
RBAC/ABAC para QA/Stage; auditoría de acceso, break-glass sólo a través de la negociación.

7) Observabilidad en entornos no prod

Los registros son estructurados, sin PII, con enmascaramiento;

Métricas latency p50/p95/p99, error-rate, throughput, DLQ, retrae;

Treking (OTel): 'trace _ id' de extremo a extremo desde la solicitud de entrada hasta el simulador;

Dashboards as Code - Los dashboards y alertas se versionan cerca del servicio.

8) Preview-envolventes efímeros (per-PR)

• PR → CI recoge la imagen, genera migraciones, eleva el namespace 'pr- ' a Kubernetes;
• se emiten URL de previsualización y tokens de usuario de prueba;
• se ha habilitado el tracking/métricas; cuando se cierra PR, se elimina el entorno.

yaml apiVersion: v1 kind: Namespace metadata:
name: pr-4821 labels:
env: preview owner: team-payments

9) Desarrollo local: Compose/Testcontainers

yaml version: "3. 9"
services:
api:
build:.
environment:
- DB_URL=postgres://postgres:postgres@db:5432/app? sslmode=disable
- KAFKA_BROKER=kafka:9092 ports: ["8080:8080"]
depends_on: [db, kafka]
db:
image: postgres:16 environment: [POSTGRES_PASSWORD=postgres]
ports: ["5432:5432"]
kafka:
image: bitnami/kafka:latest environment:
- KAFKA_ENABLE_KRAFT=yes
- KAFKA_CFG_PROCESS_ROLES=controller,broker
- KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093
- KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@localhost:9093 ports: ["9092:9092"]

Para la auto-presentación de dependencias en pruebas - Testcontainers con fixtures.

10) Pruebas de carga y estabilidad

Perfiles de carga: «torneos», «olas de pagos», «cañones masivos».
KPI: RPS, p95/p99, límites de recursos (CPU/memory), TTFB, Time-to-Wallet.
Inyección de chaos: desconexión de proveedores, aumento de latencia, «flaky» de la red.
Las políticas de Circuit breaker/backoff se verifican en Stage; las fallas van a DLQ y se replican.

11) Políticas de retroceso y replay

Replay-gateway para eventos de DLQ (modos manual/automático, filtros de llaves).
Bases de migración: arriba/abajo y abajo claros y dry-run en preview/Stage; protección contra cambios destructivos.

12) Integración con DevPortal

Directorio de sandbox y proveedores, requisitos de campo, solicitudes de ejemplo.
Botón «Vista previa abierta» en cada PR/rama; widget de métricas SLO/SLA.
Generación de colecciones SDK y Postman/Insomnia a partir de contratos.

13) Seguridad del perímetro de las cajas de arena

WAF + IP-allowlist para cajas de arena externas;

cuotas y rate limits por clave;

dominios/subdominios separados; eliminación automática de claves inactivas;

escanear las vulnerabilidades de las imágenes y las dependencias en cada billete.

14) Procesos: quién y cómo se aprovecha

Desarrolladores - local y previsualización, fidback rápido.
QA es un Test/Stage estable con datos controlados y simuladores.
Socios - Sandbox externo con DevPortal, cuotas y monitoreo.
SRE/Plataforma - perfiles de carga, caos, validación de SLO.

15) Lista de verificación de inicio de caja de arena

• Los contratos en Registry, los simuladores cubren el éxito/errores/tiempos de espera/repeticiones.
• Los datos de prueba son sintéticos, deterministas, sin PII/PAN.
• Secretos de KMS, roles limitados, auditoría habilitada.
• Métricas/trayectos/registros disponibles; alertas en error-budget y DLQ.
• Las vistas previas de Ephemeral suben a PR y se demolen automáticamente.
• Los perfiles de carga y los escenarios de caos se describen por código.
• Las políticas de migración y replicación de eventos se verifican en Stage.
• DevPortal publica gaidas y colecciones de consultas.

16) Hoja de ruta para la implementación

M0-M1 (MVP): entorno local (Compose), simulador básico PSP/KYC, pruebas de contrato en CI, previsualizaciones de neymspace en K8s.
M2-M3: catálogos de fixtures, Dashboards as Code, DLQ + replex manual, perfiles de carga.
M4-M6: Sandbox externo completo con llaves/cuotas, infraestructura de caos, SDK autógeno, política de migración «dos versiones en paralelo».
M6 +: Etapa geo-distribuida con failover, enrutamiento inteligente de proveedores por SLA en pruebas, scripts de aprendizaje automatizados en DevPortal.

17) Modelo de madurez del entorno (breve)

1. Básico: hay Test/Stage, datos manuales, aislamiento débil.
2. Avanzado - simuladores, pruebas de contrato, observabilidad, previsualización parcial.
3. Experto - el entorno per-PR, caos/carga como código, DevPortal, seguridad estricta y automatización completa.

Salida breve

Las cajas de arena y los entornos de prueba correctamente diseñados son el «airbag» y el «acelerador» de suministro. El aislamiento, la paridad con la producción, los simuladores de proveedores, los datos de prueba deterministas, la fuerte observabilidad y la automatización de los entornos de preview proporcionan un ciclo rápido y confiable de «código → validación → liberación», reduciendo el riesgo de retrocesos y simplificando la escala de la plataforma.