Costo, latencia y capas de defensa

Cada capa que se añade al camino de un mensaje suma su propia latencia: el mensaje espera a que cada una termine. También suma costo, si usa un modelo o un servicio de pago, y suma sus propios errores: una capa nueva puede bloquear clientes legítimos que las otras dejaban pasar.

La contrapartida es que capas que fallan en casos distintos reducen el riesgo más que una capa más fuerte aislada. La pregunta correcta no es cuántas capas poner, sino qué riesgo cubre cada una que no cubra otra y cuánto cuesta cubrirlo.

El presupuesto anota la latencia p95 de cada capa: el tiempo que se supera solo en una de cada veinte peticiones. Como las capas corren una detrás de otra, la latencia total aproximada es la suma de las de cada capa. La suma de percentiles es una aproximación conservadora, y es suficiente para decidir si una propuesta cabe.

Suma la latencia de las seis capas del presupuesto.

El costo se anota por cada mil mensajes, y no todas las capas cuestan: la lista, la validación y los límites corren dentro del servidor y su costo marginal es cero en esta tabla. Las capas que usan modelos sí cobran.

Calcula el costo por mil mensajes sumando las capas que cobran y llévalo al volumen diario del archivo.

El presupuesto fija una meta de latencia para la respuesta completa. Una propuesta de refuerzo cabe si, sumada a lo que ya hay, no la supera. Con el total de la tarea 2 y el margen que deja la meta, se puede decidir sin medir nada más.

Revisa las propuestas y busca la que, al sumarse, deja la respuesta fuera de la meta.

Las capas que cuestan casi nada en tiempo y dinero y que no dependen de interpretar texto, como los límites y la validación, se quedan siempre: acotan el daño sin pagar nada apreciable. Las que cuestan más, como un segundo modelo, se justifican donde el riesgo lo pida y solo si caben en la meta.

Con eso se ordena la arquitectura: primero lo barato y determinista, después lo que estima y cuesta, y se mide el efecto de cada paso en vez de suponerlo.