Este repaso estudia una plataforma hipotética de pagos real-time y liquidación batch, distribuida entre tres centros de datos y AWS. Sus decisiones y números ilustrativos sirven para razonar; no describen una instalación real ni acreditan experiencia o cumplimiento regulatorio. La explicación siguiente contiene lo necesario para seguir el caso. Las notas enlazadas amplían temas de consulta opcional.
La explicación central
Una operación aceptada tiene identidad e intención durable. Un pago confirmado tiene una decisión de negocio conocida bajo su contrato. Una liquidación reconciliada coincide con el ledger, la membresía del ciclo y la evidencia externa. Estos resultados tienen plazos y pruebas distintos: HTTP 202, un mensaje recibido o un archivo cargado no demuestran que el dinero llegó.
El ledger es la autoridad financiera. Una transacción corta registra identidad, efecto local y outbox; después se publica. Broker y workers pueden repetir entregas. Para un efecto externo se conserva intención antes de enviar y resultado después. Si se pierde la respuesta, la identidad original permite consultar qué ocurrió, sin inventar otro movimiento.
La liquidación reúne movimientos elegibles bajo calendario y fuentes completas, sella su conjunto, envía con referencias estables y concilia confirmaciones. Un total equilibrado no prueba que se incluyeron todas las instrucciones ni que se pagó al destinatario correcto. La operación SRE debe observar tanto salud técnica como ese resultado financiero.
Invariantes y datos que protegen el contrato
El journal del ledger es append-only. Una corrección autorizada añade otro asiento enlazado al anterior; no sobrescribe historia. Estados operativos y proyecciones pueden cambiar bajo transiciones válidas. operation_id, journal_id, entry_id, event_id y attempt_id son únicos y NOT NULL; unicidad que admite ausencia de identidad debilita deduplicación.
Las cantidades son enteros en unidades menores de cada moneda, con rango y overflow controlados. Decimales, redondeo, fees y FX tienen reglas explícitas. Cada asiento equilibra débitos y créditos por moneda. No se suman monedas distintas ni se delega una suma entre filas a un CHECK ordinario. La frontera transaccional controla todos los caminos de posting, disponibilidad y autorización.
| Contrato | Protección y evidencia |
|---|---|
| Un resultado válido por operación | Identidad estable, huella compatible y transición condicionada. |
| Asiento equilibrado | Conjunto completo validado dentro de la transacción autoritativa. |
| Disponibilidad suficiente | Coordinación de las cuentas afectadas bajo concurrencia. |
| Acceso del participante | Facultades comprobadas sobre operación, cuenta y moneda. |
| Corrección trazable | Nuevo movimiento autorizado y referencia al original. |
Los locks se adquieren en orden estable o se utiliza aislamiento apropiado. Serializable puede abortar y exigir reintentar toda la transacción. Un upsert resuelve determinadas carreras locales; no vuelve atómica una API externa. Consistencia y autoridad amplía estas diferencias.
Autoridad híbrida y recuperación
Elegimos un escritor financiero en DC uno y una réplica síncrona requerida en DC dos. El ACK confirmado espera persistencia local y la durabilidad remota acordada. Flush remoto no implica lectura inmediata de toda réplica. DC tres conserva recuperación y lecturas permitidas; AWS ejecuta workers y observabilidad y mantiene DR asíncrono. Cada sitio opera clústeres Kubernetes u OpenShift independientes.
--- config: look: handDrawn --- flowchart TD participant["Participante autorizado"] --> api["API por sitio<br/>Identidad y admisión"] api --> core[("DC uno<br/>Escritor único<br/>Ledger, estados y outbox")] core -->|"Persistencia síncrona"| standby[("DC dos<br/>Réplica requerida")] standby -->|"Confirmación durable"| core core -->|"ACK bajo el contrato"| api core -.->|"Recuperación y lectura"| recovery[("DC tres")] core -.->|"Replicación asíncrona"| dr[("AWS<br/>Copia para DR")] core --> relay["Relay recuperable"] relay --> workers["AWS<br/>Workers y vistas"] workers --> commands["Comandos validados"] commands --> core
La WAN puede obligar a pausar escrituras. Perder la réplica requerida no habilita degradar silenciosamente el ACK: se incorpora otra copia alcanzada y verificada bajo la política vigente, o se pausa. DR asíncrono puede perder cambios recientes y no promete RPO cero.
Antes de promover debe existir exclusión efectiva del escritor anterior: quorum y watchdog, fencing operativo o una garantía validada del motor y su despliegue. Cambiar DNS, readiness, una lease o una generación sólo en la base nueva no detiene un writer aislado que todavía ve la historia antigua. Sin prueba de cerco se pausa promoción o escritura.
El cerco de egress se verifica aparte. Un sistema externo que no valida tokens no queda protegido por el nuevo líder local. Se detiene el despacho anterior y se reconcilian instrucciones en vuelo con sus referencias originales antes de reactivar dinero. RTO incluye recuperar comportamiento funcional; RPO depende del dato y fallo, y se contrasta con pérdida observada. La recuperación se demuestra mediante ensayos.
Identidades, eventos y resultados desconocidos
Una clave idempotente vincula participante, operación y payload. Repetirla con intención compatible recupera la decisión; cambiar el payload produce conflicto. Un request ID identifica una petición; operation ID conserva la operación entre reintentos; event ID conserva el evento entre publicaciones; attempt ID sigue el intento externo. Cancelación y ejecución compiten bajo condiciones de estado y versión. Una API básica ofrece POST /payments con esa clave estable y GET /payments/{operation_id} autorizado para consultar la decisión; 202 Accepted comunica sólo admisión, no éxito financiero.
El relay puede caer después de publicar y antes de marcar progreso. El consumidor deduplica junto con su efecto local y checkpoint dentro de su frontera. Secuencia por entidad, particionado y procesamiento compatibles conservan el orden requerido; el broker no da orden global ni vuelve atómica una transferencia entre cuentas.
El recorrido externo es intención durable → envío fuera de la transacción → confirmación o UNKNOWN → consulta y reconciliación → transición condicionada. UNKNOWN no es rechazo. No se reenvía con otra identidad ni se libera o compensa dinero a ciegas. Idempotencia del proveedor tiene alcance y retención: fuera de esa garantía se resuelve evidencia antes de abrir otro intento.
Un replay reconstruye una vista; no vuelve a despachar dinero. Una lease vencida permite reclamar trabajo, pero el dueño antiguo puede regresar: se valida propiedad en el recurso y la protección externa aplicable. La ausencia de un log tampoco prueba ausencia de efecto. Los resultados inciertos conservan dueño, antigüedad y siguiente paso.
Liquidación con completitud demostrable
El calendario versiona zona horaria, días hábiles, cutoff y reglas de late arrivals. La fecha de negocio puede diferir de llegada. La frontera de fuente combina secuencias o posiciones comprobadas por productor con manifests esperados y gaps explicados. El timestamp máximo no demuestra completitud: pueden faltar registros anteriores o haber relojes desajustados.
--- config: look: handDrawn --- flowchart TD calendar["Calendario y cutoff"] --> sources["Fuentes y fronteras esperadas"] sources --> complete{"¿Completitud comprobada?"} complete -->|"No"| gap["Resolver hueco<br/>Excepción con dueño"] complete -->|"Sí"| membership["Membresía elegible"] membership --> seal[("Manifest sellado<br/>Conteos, totales y checksum")] seal --> intent[("Intención de envío durable")] intent --> send["Enviar con referencia original"] send --> external["Sistema externo"] external --> confirm["Confirmación de negocio"] send -->|"Respuesta perdida"| unknown["Resultado desconocido"] unknown --> lookup["Consultar referencia original"] lookup --> external confirm --> reconcile["Conciliar posiciones<br/>y membresía"] reconcile --> close["Cerrar o registrar discrepancias"]
La membresía conserva IDs y versiones incluidos. Se prepara desde snapshot consistente o frontera reproducible del journal, con chunks y checkpoints; el sellado comprueba el conjunto bajo coordinación corta. El manifest fija reglas, fuentes, conteos, totales por moneda y versión de artefactos. No cambia al llegar otro evento. Un ajuste conserva vínculo y autorización.
El checksum comprueba bytes, no autenticidad ni completitud. Dos movimientos omitidos pueden conservar el total neto; por eso se comparan identidades, conteos, destinatarios, fees y posiciones. Upload de objeto y registro en base son fronteras distintas y requieren reconciliación, no una atomicidad supuesta.
Se distingue acuse de transporte, aceptación de formato y confirmación financiera. Los resultados parciales conservan referencias por instrucción. Los late arrivals entran al siguiente ciclo o ajuste explícito; nunca se añaden silenciosamente al conjunto sellado. Replay y retención ayudan a recuperar evidencia sin repetir efectos.
Capacidad, SLI y presupuesto de error
Como ejemplo, seis millones de instrucciones diarias equivalen a aproximadamente 69.4 instrucciones/s de promedio; un pico hipotético ocho veces mayor equivale a 556/s. Procesar seis millones de registros en cuarenta minutos exige 2,500 registros/s antes de validar, confirmar y conciliar. Son supuestos del ejercicio, no benchmarks ni tasas garantizadas de salida externa.
Los presupuestos separan online, batch, publicación y recuperación. La suma de pools de todos los pods y workers debe caber en capacidad medida. Más conexiones no crean CPU, IO o locks disponibles. Colas acotadas por cantidad, bytes y edad conservan trabajo útil. Si el backlog crece, se compara entrada con finalización y capacidad neta de drenaje; el plazo incluye lo que todavía seguirá entrando.
| SLI | Población y condición de éxito |
|---|---|
| Admisión | Solicitudes válidas admitidas de forma durable dentro del deadline; saturación o HTTP 503 dentro del contrato cuentan como fallo. |
| Resultado | Cohortes aceptadas con tiempo suficiente para terminar y decisión durable correcta; pendientes vencidos permanecen en el denominador. |
| Ciclo | Ciclos esperados confirmados y conciliados antes de su plazo. |
| Reconciliación | Incertidumbres resueltas dentro del plazo acordado, con edad real visible. |
Cada SLO fija objetivo y ventana para su SLI. Un objetivo ilustrativo temporal de 99.9% en treinta días equivale a 43.2 minutos; no se convierte automáticamente en cuota de transacciones fallidas. Un error monetario no consume presupuesto tolerable de disponibilidad. El presupuesto SLO de ciclos no permite incumplir un cutoff contractual o regulatorio aplicable: el incumplimiento sigue siendo excepción e incidente.
Burn rate = proporción mala observada / proporción tolerada. Ventanas corta y larga ayudan a detectar consumo sostenido; cutoff e invariantes financieras requieren alertas adicionales. Ventanas sin datos no prueban éxito. Capacidad y admisión amplía cómo comprobar el margen durante fallos.
Diagnóstico por capas y evidencia
Se delimita impacto por flujo, participante, moneda, ciclo y deadline, y se asigna coordinador. Se correlaciona el inicio con releases, certificados y configuración. Después se observan DNS, TCP y TLS; workloads, CPU, memoria, threads, pools, locks, lag y backlog. Un pod Ready no demuestra liquidación correcta.
Los siguientes comandos son ilustrativos y de lectura para un laboratorio autorizado. PREP_* son placeholders de contexto y confianza esperada; no se ejecutan como parte de este repaso. Se conservan sólo salidas pertinentes sin secretos ni payloads financieros.
kubectl --context "$PREP_CONTEXT" -n "$PREP_NAMESPACE" get pods
kubectl --context "$PREP_CONTEXT" -n "$PREP_NAMESPACE" get events --sort-by=.lastTimestamp
kubectl --context "$PREP_CONTEXT" -n "$PREP_NAMESPACE" top pods
ss -s
dig "$PREP_SERVICE"
openssl s_client -connect "$PREP_HOST:443" -servername "$PREP_HOST" \
-verify_hostname "$PREP_HOST" -verify_return_error -CAfile "$PREP_CA_FILE" </dev/nullLa CA debe ser la esperada para el servicio. SNI comunica el nombre; cadena y hostname requieren verificación. mTLS acredita una identidad de certificado, pero la aplicación aún autoriza su operación de negocio. En PostgreSQL, este agregado inicial no imprime queries ni payloads:
select state, wait_event_type, count(*)
from pg_stat_activity
group by state, wait_event_type;La mitigación acotada puede limitar admisión, preservar capacidad batch o detener una expansión. Se comprueba el efecto después de cada acción. La recuperación verifica autoridad, referencias externas, pendientes, manifest y backlog drenándose; reiniciar un proceso no cierra esos resultados.
Workloads, secretos y rotación
Requests y limits se fijan con medición, incluyendo sidecars y buffers. HPA tiene retraso y se liga a capacidad útil, no sólo CPU. Readiness expresa capacidad para atender; liveness no debe causar reinicios en cadena por una dependencia compartida. PDB limita algunas interrupciones voluntarias, no pérdidas de sitio.
Draining detiene trabajo nuevo, termina lo acotado y conserva pendientes recuperables. El consumer confirma después del efecto durable. Los plazos de retiro y cierre deben concordar con conexiones y deadlines. Un rollout puede aumentar pools temporalmente; se reserva margen antes de iniciarlo.
Vault entrega secretos y certificados bajo identidad de workload y políticas acotadas. Se ensaya fallo de renovación y consumidor que conserva material válido. Rotación prepara material nuevo, convive durante una ventana acordada, hace reload o rollout y verifica conexiones nuevas y anteriores. Luego se retira material viejo bajo su contrato; revocar no cancela una instrucción ya aceptada.
Un runbook de certificado recibe entorno, servicio, versión y execution ID. Comprueba permiso, CA, hostname y material nuevo; instala de forma controlada y verifica handshake y retirada. Si se interrumpe, consulta checkpoints y versión efectiva antes de continuar. Guarda aprobaciones y pruebas sin secretos, y detiene el siguiente paso ante precondiciones fallidas. Identidad y cifrado complementa este contrato.
Entrega, runbooks y adopción de plataforma
La cadena es cambio revisado, pruebas, artefacto por digest, identidad temporal compatible, promoción acotada y señales de negocio. OIDC se configura para emisor y claims reales; no se copian entre runtimes. Gates y coordinación por entorno evitan cambios concurrentes incompatibles. Cancelar el pipeline no deshace una operación remota.
Canary o blue-green son decisiones según capacidad y compatibilidad. Expand–migrate–contract mantiene convivencia de versiones; volver al código previo no revierte asientos ni migraciones destructivas. Se conserva la evidencia del artefacto probado y del comportamiento desplegado. Entrega y rollback es consulta opcional.
Python, Java y Shell pueden implementar runbooks deterministas: precondiciones, permisos, parámetros validados, execution ID, checkpoints y postcondiciones. Repetir una ejecución consulta progreso anterior. Recuperar una vista y despachar dinero son acciones separadas. Se prueba dry run, interrupción y reanudación.
Un golden path versionado reúne interfaces de identidad, pipelines, telemetría y recuperación con owners de plataforma y servicio. Adaptadores legacy conservan IDs, estados y evidencia mientras adoptan ese contrato por rutas acotadas. Pruebas de conformidad y excepciones con dueño permiten avanzar sin reescribir el núcleo ni una migración big bang.
Alertas, incidentes y asistencia de IA
OTel correlaciona señales que Datadog u Observe organizan por impacto: resultados, pendientes por edad, progreso del ciclo y saturación. IDs detallados viven en registros o trazas controlados, no en labels métricos sin cota. Sampling y pérdida de exportación no sustituyen el registro durable; los buffers se acotan.
La severidad usa reglas deterministas versionadas sobre dinero, población y deadline. Una posible invariante rota exige contención; riesgo de cutoff exige respuesta antes de la ventana. Se conservan entradas y motivo, y un override humano queda auditado. Ante fallo del clasificador o datos insuficientes se mantiene severidad o evaluación conservadora con dueño; ausencia de señal no baja urgencia.
Las alertas se deduplican por incidente causal, tienen owner y runbook. Guardia y handoff transmiten pendientes con antigüedad y siguiente paso. El postmortem sin culpabilizar conserva cronología, factores y acciones con prueba. Mejorar toil y tiempo de diagnóstico requiere una línea base; cerrar discrepancias sin evidencia no es eficiencia.
La IA reúne evidencia autorizada y propone hipótesis y acciones. Distingue observado, inferido y desconocido. La ejecución usa herramientas acotadas y controles deterministas; no hay shell arbitrario autónomo, autocobros ni ampliación de permisos. Decisiones sobre dinero, liderazgo y credenciales siguen su protocolo operativo. Observabilidad y verificación desarrolla ese vínculo.
Evidencia y autoevaluación
Un paquete de evidencia puede reunir manifests, confirmaciones, versiones, pruebas y aprobaciones bajo una política acordada. Su job tiene execution ID, procedencia, completitud y acceso comprobados; reanudar no inventa documentación faltante. Generar el paquete no certifica cumplimiento regulatorio. Retención, redacción y restauración se verifican según política.
El coste incluye margen, copias, WAN, señales y retención. Reducir una réplica o borrar historial puede cambiar durabilidad y replay. Coste por resultado utiliza igual alcance y período en numerador y denominador. Coste y servicio ofrece más criterios.
| Pregunta de ensayo | Respuesta que debe poder demostrarse |
|---|---|
| ¿Se perdió el ACK tras commit? | Misma identidad recupera una decisión durable. |
| ¿Se perdió la respuesta externa? | UNKNOWN, referencia original y reconciliación, sin otro envío nuevo. |
| ¿Hay evento antiguo ausente al cutoff? | Gap detectado; no se fabrica completitud. |
| ¿Regresa el propietario anterior? | Cerco efectivo o pausa; egress protegido aparte. |
| ¿La copia de DR está atrasada? | Pérdida y pendientes medidos antes de habilitar salida. |
| ¿Falla rotación o telemetría? | Material y evidencia válidos, degradación acotada y dueño. |
| ¿Una nueva versión o agente propone efectos indebidos? | Detener, comprobar compatibilidad y conservar auditoría. |
Una explicación completa sigue una operación, un evento, un intento externo y un ciclo hasta sus pruebas. Para profundizar, el caso extenso de pagos y liquidación desarrolla los mismos contratos. Este repaso ya contiene el recorrido principal para estudiar y discutirlos.
Catálogo de consulta opcional
Índice de System Design · Índice de Platform Engineering