Estimation
Aproximar cantidades que cambian el diseño
Estimation es la práctica de aproximar cantidades arquitectónicamente relevantes con supuestos, unidades e incertidumbre explícitos para contrastar viabilidad e informar decisiones. Aquí se refiere a System Design: tráfico, throughput, concurrencia, almacenamiento, ancho de banda, crecimiento, capacidad, backlog y rangos de costo. La estimación de esfuerzo de proyecto, story points, horas de desarrollo o fechas de entrega pertenece a otro alcance.
La pregunta precede a la cuenta. Estimar retención ayuda si puede cambiar almacenamiento, archivo o cumplimiento; calcular requests/s por costumbre de entrevista no aporta si ninguna alternativa depende del resultado. A veces basta distinguir decenas de operaciones por segundo de millones. Otras veces una cuota cercana al pico exige mejor evidencia. Ajustar el trabajo a la decisión.
Una estimación aproxima algo desconocido; una medición observa un comportamiento bajo condiciones determinadas. Medir ayer puede informar una estimación futura, sin garantizarla. Forecast suele referirse a valores futuros, pero el uso del término varía: no hace falta imponer una taxonomía universal. Conservar qué se sabe, qué se supone y para qué horizonte.
Entradas y unidades antes que fórmulas
requirements-to-architecture ayuda a recuperar workload, latencia, retención y crecimiento cuando importan. Si faltan, anotarlos como supuestos discutibles con negocio y operación. Usuarios activos no equivalen a sesiones concurrentes ni cada acción genera exactamente una solicitud. Identificar acciones por usuario, frecuencia, tamaño, mezcla de operaciones, copias y distribución temporal.
Cada cálculo necesita unidades compatibles: solicitudes/s, bytes/registro, registros/día o segundos/operación. Convertir milisegundos a segundos antes de multiplicar tasas. Distinguir MB de MiB cuando el tamaño importa: aquí MB significa un millón de bytes y MiB, 1.048.576 bytes. El ancho de banda puede expresarse en bits/s; ocho bits corresponden a un byte, sin incluir sobrecargas del protocolo.
La precisión del resultado no supera la de las entradas. Si el negocio aproxima usuarios y acciones, una larga secuencia decimal sugiere certeza inexistente. Usar órdenes de magnitud, rangos o escenarios con motivos claros. Un intervalo supuesto no se convierte en intervalo estadístico de confianza por escribir dos extremos; explicar cómo se obtuvo.
Conservar un pequeño registro de procedencia ayuda a revisar: volumen observado durante qué período, tamaño muestreado sobre qué operaciones, retención contractual o supuesta y crecimiento basado en qué campaña. No necesita un formato obligatorio. Si dos escenarios comparten una entrada incierta, mantener esa dependencia visible: duplicar usuarios puede cambiar también mezcla y tamaños, no solo multiplicar una tasa. Quien revise debe poder sustituir un dato sin reconstruir todo el razonamiento ni confundir un ejemplo didáctico con una medición del sistema.
Del volumen a una tasa
La relación básica es tasa media = eventos / intervalo. En un ejemplo hipotético, 8.640.000 solicitudes/día / 86.400 s/día ≈ 100 solicitudes/s. El resultado es una media diaria. No describe qué ocurre durante una campaña, un batch, la apertura del servicio o un minuto de demanda concentrada.
Para Commerce, supongamos 864.000 pedidos/día / 86.400 s/día ≈ 10 pedidos/s de media. Antes de dimensionar Payments, preguntar qué proporción llega en ventanas concretas, cuántos intentos de autorización corresponden a un pedido y qué tareas adicionales concurren. Un pedido puede fallar, repetirse o no necesitar la misma secuencia que otro.
El pico debe proceder de mediciones, un escenario de negocio o una hipótesis rotulada. No existe un multiplicador mágico de diez. Si todavía no hay datos, contrastar candidatos bajo varios escenarios útiles y declarar cuál podría invalidar la propuesta. La media de navegación puede superar mucho a checkout sin que eso obligue a separar servicios.
Throughput, latencia y concurrencia
Throughput cuenta trabajo completado por unidad de tiempo; latencia mide duración por operación; concurrencia cuenta operaciones presentes simultáneamente. La tasa ofrecida tampoco es necesariamente throughput: ante rechazo, acumulación o fallo puede entrar más trabajo del que se completa. Mantener la misma población y frontera al comparar cantidades.
Completar más operaciones por segundo no garantiza reducir su latencia: un cambio puede aumentar throughput y, al mismo tiempo, agregar espera a cada operación.
Una media no determina p95 o p99. Estos percentiles describen la distribución de duración y no se sustituyen por el promedio en una relación de promedios. Un escenario de quality-attribute-scenarios puede exigir p95 bajo determinada carga; comprobarlo necesita evidencia de esa distribución. Una cuenta de concurrencia media no demuestra ese requisito.
Little’s Law relaciona L = λW: número medio presente, tasa media de entrada y tiempo medio de permanencia en el mismo sistema. Las notas de Karl Sigman, Columbia, secciones 1.1–1.2 presentan la relación con límites de largo plazo existentes y finitos, y muestran por qué elegir la frontera importa.
Para usarla aquí, trabajar con flujo estable y balanceado: tasas de entrada efectiva y salida compatibles, medias representativas y población consistente. Si se incluye espera más servicio en W, incluir ambas poblaciones en L. No inferir estabilidad a partir de una ventana corta ni aplicar ciegamente la cuenta a una cola que crece indefinidamente o a un transitorio abrupto.
Ejemplo hipotético: 200 autorizaciones/s × 0,5 s/autorización ≈ 100 autorizaciones en curso de media en la etapa delimitada. No significa cien conexiones de base de datos ni recomienda ese pool. Su ocupación, frontera y tiempo relevante serían distintos. Si los 0,5 s fueran p95, la multiplicación dejaría de ser esta estimación de promedio.
Carga, capacidad y recurso limitante
La carga describe trabajo presentado; la capacidad es el trabajo sostenible bajo un workload, recursos y objetivos de calidad determinados. Una cifra de capacidad sin mezcla de solicitudes, duración y comportamiento de fallo deja abierta la pregunta principal. scaling conecta cambios de demanda y recursos con la unidad efectiva de crecimiento.
Más utilización puede aumentar espera y reducir margen, pero no hay un umbral universal de 70 % u 80 %. El headroom responde a ráfagas, crecimiento, despliegues o fallos pertinentes; tampoco exige siempre duplicar capacidad o reservar un porcentaje fijo. Si sobrevivir a perder un nodo o una zona es un driver, estimar ese escenario explícitamente.
Cuotas del proveedor, conexiones de base, contención o un componente serial pueden dominar antes que CPU del frontend. Replicar aplicaciones no incrementa automáticamente la capacidad de esos límites. Tráfico diferente entre Browse y Payments ayuda a examinar unidades de granularity y scaling, pero no selecciona una frontera independiente por sí solo.
Almacenamiento y red con alcance visible
Una primera aproximación es registros/día × bytes/registro × días retenidos. Para Commerce, supongamos un millón de eventos de pago diarios, unos 2.000 bytes por evento y treinta días: 1.000.000 × 2.000 × 30 ≈ 60 GB decimales de payload crudo. La redondez refleja un ejemplo, no un sizing de producción.
Agregar lo que corresponda: índices, metadata, versiones, réplicas, backups y copias de auditoría. Compresión y formatos también cambian la huella. Multiplicar payload por réplicas aproxima solo esa parte de las copias, no toda la infraestructura ni su costo. Verificar qué se conserva y cómo se contabiliza antes de sumar categorías que podrían solaparse.
Retención, borrado, compactación y archivo modifican el crecimiento. Con una ventana fija, el volumen puede estabilizarse después de llenarla bajo demanda constante; con archivo permanente continúa acumulándose en otro lugar. No proyectar crecimiento lineal infinito sin definir la política. Variar demanda y payload ayuda a detectar qué supuesto domina.
Para red, partir de transferencias/s × bytes/transferencia. En un ejemplo de 200 eventos/s y 2.000 bytes, son unos 400.000 bytes/s de payload, aproximadamente 3,2 Mbit/s. Cabeceras, cifrado, compresión, reintentos, replicación y destinos adicionales cambian el tráfico real. Distinguir tráfico interno y salida facturable según la decisión, sin usar precios actuales.
Trabajo derivado y acumulación
Una solicitud externa puede generar fan-out, varias consultas, transacciones o escrituras con índices. La mezcla lectura/escritura, tamaño y complejidad importan tanto como requests/s. Cien lecturas pequeñas y cien reportes con agregaciones no representan el mismo trabajo de base. Relacionar cada operación relevante con el recurso que consume, evitando equiparar usuarios/s con carga interna.
retry y retry-storms obligan a contrastar también degradación: repeticiones y clientes sincronizados pueden amplificar demanda cuando una dependencia dispone de menos capacidad. No aplicar automáticamente un multiplicador máximo a todo el tráfico; declarar tasa de fallos, límites, distribución temporal y trabajo que llega a ejecutarse. El modo degradado puede ser el escenario decisivo.
Si las llegadas sostenidas superan las finalizaciones, crece el backlog. Bajo tasas constantes y trabajo comparable, una aproximación de vaciado es backlog / (finalizaciones/s - nuevas llegadas/s), solo cuando el denominador es positivo. Con 6.000 pendientes, 150 finalizaciones/s y 100 llegadas/s, serían unos 120 segundos. Ignorar las llegadas daría cuarenta segundos y una expectativa equivocada.
Batching, paralelismo, variación de tamaños, fallos y reintentos pueden invalidar esa simplificación. queue-management, backpressure y overload mantienen los mecanismos en sus canónicos. La cuenta identifica una pregunta de viabilidad; no demuestra que una cola ilimitada proteja al sistema ni prescribe una política de admisión.
Commerce: cuota externa y sensibilidad
Supongamos una cuota contractual hipotética de 250 solicitudes/s al proveedor y un pico estimado de 200 intentos/s, ya incluyendo el trabajo inicial relevante. Quedan nominalmente cincuenta solicitudes/s, pero eso no demuestra margen suficiente: comprobar ventana de cuota, otras operaciones, ráfagas y reintentos. Si la degradación agrega cien intentos/s, el escenario excede ese límite. Más réplicas de Commerce no lo corrigen.
Revisar qué entrada cambia la decisión. Duplicar la tasa de autorizaciones del ejemplo, manteniendo la media de 0,5 s, aproxima doscientas en curso; duplicar esa media con la tasa original produce lo mismo. Multiplicar payload por cinco cambia almacenamiento y transferencia asociados por cinco bajo los demás supuestos constantes. Son exploraciones locales de sensibilidad, no pronósticos ni un nuevo score.
Si producción revela p95 distinto del promedio supuesto, investigar la distribución y medir también la media para actualizar Little’s Law. El percentil informa el escenario de latencia; no reemplaza directamente W. Comparar crecimiento previsto con observado y revisar entradas cuando cambien clientes, campañas, proveedor o políticas de retención.
Costos y comprobación
common-pitfalls examina falsas certezas como media usada como pico o multiplicadores sin evidencia. design-exercises permite practicar cuentas dirigidas por una decisión y revisarlas al revelar una cuota o cambiar el workload, manteniendo visibles unidades, supuestos y límites de la aproximación.
Un rango de costo puede incorporar cómputo, almacenamiento, red, servicios gestionados, observabilidad, operación y transición. cost-efficiency conserva su relación con resultados útiles. Uso, región, modelo de cobro, descuentos, egress, logs y capacidad ociosa introducen incertidumbre: separar supuestos y escenarios en lugar de presentar una factura exacta o recomendar proveedores.
Un benchmark mide un workload en un ambiente; un load test ejecuta demanda contra una implementación; monitoring aporta observaciones operativas. Una estimación puede preceder al código y orientar qué medir. Ninguna prueba aislada garantiza producción. Google SRE, Production Services Best Practices relaciona planificación de capacidad con contraste de previsiones y uso real, y pruebas que actualizan las relaciones entre recursos y demanda.
Evidencia dentro de la síntesis
deep-dives puede investigar si la cuota de Payments soporta el pico; estimar primero muestra si hace falta un benchmark o negociar capacidad. high-level-design conserva cantidades que condicionan fronteras o compromisos, sin llenarse de cuentas irrelevantes. architectural-drivers explica por qué ese workload o límite merece atención.
La relación con trade-off-analysis es bidireccional: comparar alternativas descubre cantidades decisivas; estimarlas aporta evidencia y puede cambiar la comparación. Como síntesis del Atlas, formular pregunta, candidatos, drivers, consecuencias e incógnitas; producir evidencia dirigida; decidir, experimentar o fijar una revisión. Estimation aproxima magnitudes, Trade-off Analysis interpreta consecuencias y Design Process mantiene el ciclo más amplio.