ATALAIA
  1. Inicio
  2. Servicios
  3. Revisión de arquitectura
02Estación 02 · Diseño

Revisión de arquitectura

Leemos el diseño antes del primer commit: dónde los datos cruzan una frontera, qué servicio confía en cuál y qué se rompe si uno de ellos falla.

Dónde cambia la confianza

Cuatro zonas, las llamadas entre ellas y las cuatro juntas que encontró la revisión. Cada pin es una decisión, no un hallazgo.

INTERNETEDGECLUSTERDATOSmensaje de créditoconfiado por redstaging + prod/adminUsuariosPartnersexternoGatewayauthPanel de administraciónOfertasservicioColacréditosLedgerservicioLedger DBClave de firmasecret1234
  1. 1
    El ledger confía en cualquier llamante del clúster

    Cambio: identidad de servicio (mTLS) en cada llamada al ledger.

  2. 2
    Cualquier pod puede publicar un crédito

    Cambio: mensajes firmados, y solo el servicio de ofertas puede publicar.

  3. 3
    Una sola clave de firma para staging y prod

    Cambio: una clave por entorno, guardada en el servicio de claves.

  4. 4
    Ruta de administración accesible desde internet

    Aceptado durante un sprint, después tras la VPN. Registro de decisión #12.

La revisión, tal como ocurre

Elige un paso o déjalo correr. Cada línea es lo que alguien dice de verdad en la sala.

Paso 1Lee el diseño

Docs, diagramas y un walk-through con quienes los construyeron.

ARQUITECTOAquí está rewards: un gateway, el ledger, ofertas y una cola entre ellos.

ATALAIA¿Quién llama al ledger directamente? ¿Algo que no sea el gateway?

DEV LEADEl servicio de ofertas. Está dentro del clúster, así que lo dejamos pasar.

Sale de la salaDocumentación leída, 1 walk-through

Paso 2Marca las boundaries

Identidad, red, datos y límites de tenancy en una sola imagen.

ATALAIAAsí que el ledger confía en cualquier cosa de la red. Es un límite que nadie dibujó.

PLATAFORMALa cola también. Cualquier pod puede publicar un mensaje de "puntos acreditados".

Sale de la salaMapa: 4 boundaries marcadas

Paso 3Somete las uniones a estrés

Qué hace un atacante, un mal deploy o una clave filtrada en cada frontera.

ATALAIASi un pod queda comprometido, ¿puede acreditarse puntos a sí mismo?

PLATAFORMAHoy, sí. Parecería un mensaje normal.

ARQUITECTOY una sola clave firma los tokens en staging y en prod.

Sale de la sala6 uniones sometidas a estrés, 2 de riesgo alto

Paso 4Acordad los cambios

Cambios ordenados por prioridad, con los compromisos por escrito.

ATALAIAIdentidad de servicio en el ledger, mensajes firmados, una clave por entorno.

CTOClaves e identidad este trimestre. La reescritura de la cola espera, y lo aceptamos por escrito.

ARQUITECTOHoy mismo escribo el registro de decisión.

Sale de la sala3 cambios, 1 riesgo aceptado

  • ATALAIA
  • ARQUITECTO
  • DEV LEAD
  • PLATAFORMA
  • CTO

Qué sale mal

Los hallazgos más caros son decisiones de diseño: un secreto compartido, un servicio que confía en cualquier llamante, una ruta de admin que nadie acotó. Son baratos en una pizarra y caros en producción.

SEÑALES DE QUE ESTÁS AQUÍ

  • Las llamadas entre servicios se autentican por ubicación en la red
  • Un token o clave abre varios entornos
  • El diagrama de la wiki lleva dos reescrituras de retraso

Qué recibes

  • Un diagrama de arquitectura revisado con las trust boundaries marcadas
  • Riesgos de diseño ordenados por impacto y coste de cambio
  • Alternativas concretas, no solo objeciones
  • Un registro de decisión breve para cada riesgo aceptado

Formato típico: De una a dos semanas por sistema, según su tamaño.

Habladlo

Una llamada de 30 minutos. Sin diapositivas, sin lista de precios y con un siguiente paso en cualquier caso.