Saltar a contenido

Capítulo 19

Costos, escalabilidad y buenas prácticas

Cómo diseñar infraestructura profesional que crezca sin desperdiciar dinero

Objetivo

Este capítulo busca que el lector aprenda a diseñar infraestructuras modernas pensando no solo en que funcionen, sino en que sean económicas, escalables, seguras y fáciles de mantener. En otras palabras, no basta con que una aplicación “corra”; debe crecer sin desbordar el presupuesto, sin obligar a rediseños traumáticos y sin introducir riesgos innecesarios.[web:170][web:173][page:2][web:182][web:198][web:191]

Al finalizar, el lector será capaz de estimar costos aproximados, entender cómo cobran los principales proveedores cloud, identificar cuellos de botella, elegir una arquitectura razonable para cada etapa de crecimiento y aplicar buenas prácticas que reduzcan gasto operativo sin sacrificar rendimiento ni seguridad.[page:1][page:2][web:142][web:197][web:198][web:191]

¿Qué significa escalar?

La palabra escalar suele usarse de forma imprecisa. Muchas veces se confunde con “tener más usuarios”, pero en infraestructura significa algo más profundo: aumentar la capacidad de un sistema para atender mayor carga sin perder estabilidad, rendimiento ni control de costos.

Imagina una cafetería. Si hoy atiende a 20 personas por hora y mañana atiende a 200, no basta con decir que “creció”. Hay que observar si los pedidos siguen saliendo rápido, si no faltan insumos, si el personal no se satura y si el local sigue siendo rentable. En software pasa exactamente lo mismo.

Escalabilidad

La escalabilidad es la capacidad de una arquitectura para soportar más usuarios, más datos, más peticiones o más procesos sin romperse ni disparar innecesariamente el costo.[page:1][page:2][web:182]

Crecimiento

Crecimiento significa aumento de demanda: más usuarios, más archivos, más lecturas, más correos enviados, más consultas a APIs o más consumo de CPU. Escalabilidad es la capacidad de absorber ese crecimiento de manera ordenada.

Disponibilidad

Un sistema que escala pero se cae cada vez que sube el tráfico no está bien diseñado. La disponibilidad mide qué tan probable es que el servicio siga funcionando cuando se le necesita. GitHub Enterprise Cloud publica un SLA de 99.9% de disponibilidad mensual, lo que ilustra cómo la disponibilidad se vuelve parte contractual y no solo técnica cuando un sistema madura.[web:199]

Rendimiento

Rendimiento es la velocidad y eficiencia con que el sistema responde. Puede haber una aplicación disponible, pero si tarda ocho segundos en cargar o en guardar un registro, el usuario la percibirá como defectuosa.

Elasticidad

Elasticidad es la capacidad de ajustar recursos según la demanda real. En la nube moderna, muchos servicios cobran por uso y permiten crecer o reducir carga sin administrar directamente servidores. Workers cobra por solicitudes y CPU consumida, D1 cobra por filas leídas, escritas y almacenamiento, y R2 por almacenamiento y operaciones, sin cargos de egreso a Internet.[page:1][web:173][page:1]

Un ejemplo sencillo

Supón una plataforma educativa con 1,000 alumnos. Si durante la mayor parte del día hay poca actividad, pero entre 7:00 y 8:00 p. m. todos entran a revisar tareas, una arquitectura elástica se adapta a ese pico y luego vuelve a un costo bajo. Una infraestructura fija y sobredimensionada, en cambio, se paga completa todo el tiempo, incluso cuando está ociosa.

Escalabilidad vertical

La escalabilidad vertical consiste en hacer más grande una sola máquina o una sola unidad de cómputo. Es como cambiar una camioneta por un camión más grande sin cambiar la carretera.

¿Qué es?

En términos tradicionales, significa aumentar CPU, memoria, disco o capacidad de una sola instancia. En cloud puede tomar la forma de elegir un plan superior, asignar más memoria a una función o migrar a una base de datos más robusta.

Ventajas

  • Es fácil de entender.
  • Requiere menos cambios arquitectónicos al inicio.
  • Resulta útil cuando el sistema todavía es pequeño o medianamente simple.
  • Simplifica el troubleshooting porque hay menos piezas distribuidas.

Desventajas

  • Tiene un límite físico o económico.
  • Crea dependencia en un solo punto más potente, pero también más delicado.
  • Si esa pieza falla, el sistema entero puede verse afectado.
  • Suele ser una solución temporal más que estratégica.

Casos de uso

La escalabilidad vertical tiene sentido cuando:

  • El sistema todavía está en fase MVP.
  • El cuello de botella es claro y único.
  • La complejidad de distribuir el sistema todavía no se justifica.
  • Se trata de una base de datos o servicio que aún no requiere partición lógica.

Escalabilidad horizontal

La escalabilidad horizontal consiste en agregar más instancias, más nodos o más puntos de servicio en lugar de hacer una sola pieza más grande. Siguiendo la analogía anterior, en vez de comprar un camión enorme, se habilitan varios vehículos trabajando juntos.

¿Qué es?

Es el modelo más asociado a la nube moderna. Los sistemas serverless y distribuidos se apoyan mucho en este principio. Workers, por ejemplo, se ejecuta sobre la red global de Cloudflare y permite responder solicitudes desde una plataforma distribuida sin que el desarrollador administre servidores individuales.[page:1][web:171]

Balanceadores

Cuando hay varias instancias de un servicio, hace falta distribuir el tráfico. Tradicionalmente eso se hace con balanceadores. En arquitecturas modernas, parte de esa distribución puede estar absorbida por el propio proveedor perimetral o por el diseño serverless.

Replicación

La replicación permite que varias copias de datos o servicios estén disponibles para lectura, resiliencia o proximidad geográfica. Cloudflare documenta que D1 ofrece replicación de lectura sin cargo adicional por réplicas, y que la facturación sigue basándose en filas leídas y escritas.[page:1]

Ventajas

  • Permite crecer por etapas.
  • Reduce dependencia en un solo nodo.
  • Mejora la tolerancia a fallos.
  • Se alinea mejor con arquitecturas distribuidas y picos variables.

Desventajas

  • Introduce complejidad de coordinación.
  • Exige mejor observabilidad.
  • Puede complicar consistencia, depuración y despliegues.
  • Requiere pensar en estado, sesiones, caché y concurrencia.

Alta disponibilidad

Escalar no basta. También hay que resistir fallos.

Redundancia

Redundancia significa no depender de una sola pieza crítica. Puede haber redundancia de archivos, de rutas, de instancias, de regiones o incluso de proveedores.

Failover

Failover es el mecanismo por el cual, si una pieza deja de responder, otra asume su función. A veces es automático; a veces requiere intervención. Cuanto más crítica es la aplicación, más automatizado debe ser el failover.

Replicación

Replicar datos y servicios no solo ayuda a escalar lecturas; también mejora resiliencia. Sin embargo, replicar sin entender consistencia puede producir sistemas que parecen robustos, pero responden con datos desactualizados o incompletos.

Regiones

En proveedores tradicionales, la región es una decisión crítica de costo, latencia y resiliencia. En plataformas perimetrales como Cloudflare parte de la distribución está más abstraída para el desarrollador, aunque ciertos recursos concretos sigan teniendo reglas particulares.[web:171][page:1]

Backups

Todo sistema profesional necesita respaldos. Un backup no es lo mismo que replicación. La replicación ayuda frente a fallos inmediatos; el backup ayuda frente a corrupción, borrados accidentales, errores humanos o incidentes de seguridad.

Recuperación ante desastres

La recuperación ante desastres consiste en responder la pregunta incómoda: si mañana se daña una base crítica, un bucket, una cuenta o una integración entera, ¿cómo se recupera el sistema y en cuánto tiempo? Si no existe una respuesta escrita, la arquitectura todavía está incompleta.

Diseño para crecer

No se diseña igual para 100 usuarios que para 1 millón. La clave está en no sobredimensionar desde el inicio, pero tampoco encerrarse en una arquitectura que obligue a reescribir todo demasiado pronto.

Etapa 1: 100 usuarios

En esta etapa conviene priorizar simplicidad y velocidad. Una arquitectura con Cloudflare Pages para frontend, Workers para lógica ligera y uno o dos servicios de datos bien elegidos puede ser suficiente.[web:171][page:1]

Lo importante aquí no es tener una plataforma espectacular, sino validar que el producto resuelve un problema real. Gastar demasiado pronto suele ser una señal de mala arquitectura o de ansiedad técnica.

Etapa 2: 1,000 usuarios

A partir de aquí aparecen patrones de uso reales. Ya vale la pena medir:

  • páginas más vistas,
  • endpoints más usados,
  • lecturas por usuario,
  • tráfico de archivos,
  • costos por operación.

También empieza a ser importante distinguir entre datos calientes, datos fríos, archivos pesados y rutas críticas.

Etapa 3: 10,000 usuarios

Con 10,000 usuarios ya se vuelve visible todo lo que estaba mal modelado. Una consulta SQL sin índice empieza a doler. Un documento Firestore mal estructurado se vuelve caro. Un flujo de archivos sin caché consume más ancho de banda del necesario. En esta etapa se vuelve imprescindible revisar cuidadosamente las métricas de cada servicio.[page:1][page:2]

Etapa 4: 100,000 usuarios

Ahora el sistema ya no puede depender solo de intuiciones. Debe existir:

  • observabilidad real,
  • separación clara entre panel administrativo y tráfico público,
  • controles de rate limiting,
  • políticas de retención,
  • arquitectura modular.

A este nivel, la pregunta ya no es “¿funciona?”, sino “¿funciona sin desperdiciar dinero y sin crear fragilidad?”

Etapa 5: 1,000,000 usuarios

A un millón de usuarios, el costo de los pequeños errores se multiplica. Un mal patrón de lectura en Firestore, una API mal cacheada o un archivo servido sin optimización puede representar una diferencia enorme en facturación. Aquí las decisiones arquitectónicas pesan más que nunca.

Diseño modular

Monolitos

Un monolito es una aplicación donde casi todo vive en una sola unidad lógica. No siempre es algo malo. De hecho, muchos proyectos pequeños deberían comenzar con cierto grado de monolito, siempre que esté bien organizado.

Microservicios

Los microservicios separan el sistema en piezas independientes. Son poderosos, pero caros en complejidad. Adoptarlos demasiado pronto puede ser un error peor que mantener un monolito ordenado.

Servicios desacoplados

Existe un punto intermedio muy práctico: servicios desacoplados por responsabilidad. Por ejemplo:

  • frontend en Pages,
  • autenticación en Firebase Auth,
  • archivos en R2,
  • email en SES,
  • lógica pública en Workers,
  • módulo relacional en D1.

Ese enfoque no necesita microservicios extremos, pero sí fronteras claras.

APIs

Las APIs son la forma más habitual de desacoplar módulos. Permiten que el frontend, el panel administrativo, integraciones externas o automatizaciones trabajen sobre contratos definidos.

Eventos y colas

Cuando un proceso no necesita respuesta inmediata, conviene sacarlo del flujo síncrono. Cloudflare Queues cobra por operaciones y permite desacoplar procesamiento de mensajes, evitando que tareas pesadas bloqueen el request principal.[page:1]

¿Cuándo utilizar cada enfoque?

  • Monolito organizado: al inicio o en productos pequeños.
  • Servicios desacoplados: cuando hay módulos con responsabilidades distintas.
  • Microservicios: cuando la escala, el equipo o la complejidad ya justifican una frontera operativa fuerte.
  • Eventos y colas: cuando hay trabajo asincrónico, reintentos o procesos pesados.

Optimización de costos

Optimizar costos no significa “abaratar todo”. Significa gastar donde produce valor y eliminar gasto inútil.

Cloudflare

Cloudflare es fuerte cuando el problema central es servir frontend rápido, ejecutar lógica edge y reducir dependencia en servidores tradicionales. Workers Paid tiene un costo base de 5 USD mensuales, incluye 10 millones de requests al mes y 30 millones de milisegundos de CPU, y cobra después por request y CPU adicional.[page:1]

Eso lo vuelve particularmente eficiente para proyectos donde mucha parte del tráfico es estática o ligera, sobre todo porque los assets estáticos en Pages son gratuitos e ilimitados y las solicitudes a activos estáticos no se cobran como invocaciones dinámicas.[page:1][web:181]

R2

R2 es especialmente interesante cuando el sistema sirve muchos archivos hacia Internet, porque no cobra egreso. La documentación oficial indica 0 cargos por egress, 0.015 USD por GB-mes en almacenamiento estándar, 4.50 USD por millón de operaciones Class A y 0.36 USD por millón de operaciones Class B, con un nivel gratuito incluido.[page:1]

Eso cambia completamente la conversación frente a arquitecturas donde el tráfico de salida se vuelve el costo dominante.

Caché

Una respuesta cacheada es, en muchos casos, una respuesta que no vuelve a tocar la base de datos ni la función dinámica. La caché reduce costo, latencia y carga simultáneamente. Es difícil encontrar una optimización más rentable.

Workers

Los Workers se optimizan de varias formas:

  • menos invocaciones innecesarias,
  • menos CPU por request,
  • más caché,
  • menos serialización pesada,
  • separación de rutas estáticas y dinámicas.

Cloudflare no cobra duración ni ancho de banda en Workers Standard, pero sí requests y CPU consumida, por lo que optimizar CPU sigue siendo importante.[page:1]

CDN

Usar CDN reduce latencia y descarga origen. Esto no solo mejora rendimiento; también evita que el backend procese solicitudes repetidas para recursos inmutables.

Compresión

Brotli y otras técnicas de compresión reducen bytes transferidos. Menos bytes significan menos tiempo de carga y, en servicios con cobro por transferencia, menos costo.

Lazy loading

No todo debe cargarse de inmediato. Si una pantalla muestra diez imágenes, pero solo dos están en el viewport inicial, lo razonable es cargar primero esas dos.

Optimización de imágenes

Formatos como WebP y AVIF pueden reducir notablemente tamaño sin degradar demasiado la calidad visual. En proyectos educativos con muchas fotos, esto tiene impacto directo en almacenamiento, transferencia y experiencia móvil.

Consultas SQL

En D1, el costo depende de filas leídas y escritas. Eso significa que una consulta ineficiente puede salir cara aunque la tabla no sea enorme. Cloudflare documenta que los índices reducen las filas leídas y, en la mayoría de los casos, compensan ampliamente las escrituras extra que introducen.[page:1]

Uso eficiente de Firestore

Firestore puede ser rapidísimo para construir producto, pero se vuelve caro cuando se lee demasiado o se modela mal. Optimizar Firestore suele implicar:

  • documentos más bien diseñados,
  • lecturas más pequeñas,
  • evitar listeners innecesarios,
  • reducir lecturas repetidas de interfaces mal estructuradas.

La página oficial de Firebase deja claro que Firestore cobra por almacenamiento, lecturas, escrituras y egreso una vez superados los límites gratuitos.[page:2]

Uso eficiente de Storage

Tanto Firebase Storage como otros servicios de objetos requieren pensar no solo en almacenamiento, sino en descargas, operaciones y patrones de acceso. Si los mismos archivos se leen miles de veces, la caché y el CDN cambian radicalmente el costo final.

Uso eficiente de Amazon SES

SES suele ser muy bueno para correo transaccional, pero debe usarse con higiene: plantillas eficientes, verificación de dominios, control de rebotes, evitar duplicidades y separar correos críticos de campañas ruidosas.

Uso eficiente de Amazon Polly

Polly agrega valor cuando la accesibilidad o la voz sintética producen beneficio claro. Si se usa indiscriminadamente para generar audio que nadie consume, se convierte en costo ornamental.

Costos reales

Cómo calcular costos en Cloudflare

Cloudflare utiliza modelos por uso en buena parte de su plataforma de desarrollo. Algunos ejemplos oficiales:

  • Workers Paid: 5 USD base al mes, 10 millones de requests incluidos y 30 millones de CPU ms incluidos; después cobra 0.30 USD por millón de requests adicionales y 0.02 USD por millón de CPU ms adicionales.[page:1]
  • D1: 25 mil millones de filas leídas al mes incluidas, 50 millones de filas escritas incluidas y 5 GB incluidos; después cobra 0.001 USD por millón de filas leídas, 1 USD por millón de filas escritas y 0.75 USD por GB-mes.[page:1]
  • R2: 10 GB-mes gratuitos, luego 0.015 USD por GB-mes; 1 millón de operaciones Class A gratis, luego 4.50 USD por millón; 10 millones de operaciones Class B gratis, luego 0.36 USD por millón; egreso gratuito.[page:1]
  • Pages Functions: cuentan como requests de Workers; los assets estáticos son gratis e ilimitados.[web:181]

Cómo calcular costos en Firebase

Firebase mezcla un plan gratuito con un modelo Blaze pay-as-you-go. La página oficial indica, entre otros valores:

  • Authentication con Identity Platform: hasta 50K MAUs sin costo para ciertos servicios.[page:2]
  • Cloud Firestore Standard: hasta 1 GiB de almacenamiento, 10 GiB/mes de egreso, 20K escrituras por día, 50K lecturas por día y 20K borrados por día sin costo; después aplica precios de Google Cloud.[page:2]
  • Cloud Functions: 2 millones de invocaciones por mes sin costo, luego 0.40 USD por millón, además de CPU, memoria y salida de red según uso.[page:2]
  • Firebase Hosting: hasta 10 GB de almacenamiento sin costo y 360 MB/día de transferencia, luego 0.026 USD/GB de almacenamiento y 0.15 USD/GB de transferencia.[page:2]
  • Cloud Storage for Firebase: el cobro depende del tipo de bucket y se procesa como tarifas de App Engine o Google Cloud Storage según el caso.[page:2]

Cómo calcular costos en AWS

AWS cobra por uso en casi todos sus servicios, pero con una granularidad más amplia y, a menudo, más compleja. Algunos ejemplos oficiales:

  • Lambda cobra por requests y duración en GB-segundos.[web:182]
  • S3 cobra almacenamiento, requests y transferencia según clase y región.[web:59]
  • CloudWatch cobra por métricas, logs, alarmas y otros componentes observables.[web:142]
  • SES cobra por región y cuenta, con elementos adicionales según el tipo de uso.[web:197]

Cómo calcular costos en GitHub

GitHub no es solo repositorios; también puede formar parte del costo operativo por Actions, almacenamiento de paquetes, Codespaces y planes organizacionales. GitHub Free incluye repositorios privados ilimitados, 2,000 minutos de Actions para ciertos casos y Pages en repositorios públicos; GitHub Team añade 3,000 minutos de Actions al mes para privados y GitHub Enterprise Cloud incluye 50,000 minutos y 50 GB de Packages, además de SAML, audit log streaming e IP allow list.[web:199][web:198]

Cómo calcular costos en Google Workspace

Google Workspace también puede entrar en el presupuesto institucional. La documentación oficial muestra que Business Starter cuesta 8.40 USD por usuario/mes en flexible o 7 USD por usuario/mes en plan anual, mientras Business Standard cuesta 16.80 USD flexible o 14 USD anual, con diferencias importantes en almacenamiento y funciones colaborativas.[web:191]

Cómo leer una factura Cloud

Una factura cloud puede parecer intimidante porque no cobra “el sistema”, sino el comportamiento del sistema.

Storage

Es el volumen almacenado durante el tiempo facturado, normalmente en GB-mes. Un archivo de 1 GB guardado durante todo el mes equivale, aproximadamente, a 1 GB-mes.

Bandwidth o transferencia

Es la cantidad de datos transferidos. En algunos proveedores esta línea domina rápidamente la factura. Cloudflare destaca porque R2 no cobra egreso a Internet y Workers no cobra ancho de banda en su modelo Standard.[page:1]

Requests

Cada request es una unidad de invocación o acceso. Workers cobra por requests de entrada al Worker; las solicitudes a assets estáticos no cuentan como requests billables dinámicos.[page:1][web:181]

Reads y writes

D1 mide filas leídas y escritas. Firestore mide operaciones de lectura, escritura y borrado. Esto obliga a diseñar consultas y documentos con conciencia de costo.[page:1][page:2]

CPU time

Workers cobra por CPU consumida, no por tiempo total de espera. Lambda cobra por duración en función de memoria asignada y tiempo ejecutado.[page:1][web:182]

Invocaciones

Las invocaciones son cuántas veces se llama una función o servicio. Cloud Functions, Lambda y otros runtimes basan parte de su costo en este patrón.

Operaciones

R2 distingue entre Class A y Class B. Las Class A suelen mutar estado; las Class B suelen leer estado existente. Esa distinción obliga a pensar en el comportamiento del producto, no solo en el tamaño de los archivos.[page:1]

Monitoreo

Una infraestructura sin monitoreo es una infraestructura ciega.

Logs

Los logs explican qué pasó. Workers Logs incluye 200,000 eventos al día en Free y 20 millones al mes incluidos en Paid, con retención distinta por plan.[page:1]

Analytics

Las analíticas muestran qué tan usado está el sistema, qué rutas son críticas y dónde hay picos anormales. No sirven solo para marketing: sirven para detectar gasto inútil.

Cloudflare Analytics

Cloudflare ofrece analítica y observabilidad a distintos niveles de su plataforma, y permite complementar con datos específicos para Workers o servicios concretos.[page:1]

Firebase Analytics

Firebase Analytics sigue siendo una pieza fuerte para medir eventos de producto y comportamiento de usuario, y aparece como producto sin costo en la página oficial de precios.[page:2]

CloudWatch

CloudWatch es el centro de observabilidad tradicional en AWS para logs, métricas y alertas, pero su propio uso también debe presupuestarse y controlarse.[web:142]

Alertas y métricas

No basta con almacenar datos observables. Hay que convertirlos en señales accionables:

  • consumo inesperado,
  • errores 5xx,
  • aumento de latencia,
  • crecimiento súbito en writes,
  • descargas anómalas,
  • fallo de integraciones.

Seguridad operativa

Copias de seguridad

Toda arquitectura profesional necesita backups programados y verificados. Un backup que nunca se probó restaurar es solo una ilusión de seguridad.

Versionado

Versionar código, infraestructura declarativa y ciertos activos críticos permite revertir errores rápidos y auditar cambios.

Auditoría

La auditoría debe registrar acciones sensibles, cambios administrativos y accesos relevantes. GitHub Enterprise Cloud incluye audit log streaming e IP allow list, lo que muestra cómo la seguridad operativa madura también llega a la capa de desarrollo y repositorio.[web:199]

Logs y alertas

Los logs sin alertas generan cementerios de datos. Las alertas sin contexto generan fatiga. Hay que equilibrar ambas cosas.

Rotación de claves

Los secretos deben rotarse periódicamente. Mantener llaves antiguas eternamente es una deuda de seguridad silenciosa.

Control de acceso

No todos necesitan acceso a todo. La regla sana es mínimos privilegios, tanto en nube como en repositorios y paneles.

Optimización del rendimiento

HTTP/3

HTTP/3 mejora el transporte y puede reducir fricción en redes inestables. No arregla por sí solo una mala arquitectura, pero suma en experiencia real.

CDN y cache

Una buena estrategia de CDN y cache es casi siempre la optimización más rentable: mejora velocidad y reduce costo simultáneamente.

Brotli

Brotli reduce tamaño de assets textuales, mejorando transferencia y experiencia de usuario.

WebP y AVIF

Ambos formatos suelen reducir peso frente a PNG o JPEG tradicionales. En plataformas con muchas fotos o banners, el ahorro acumulado puede ser significativo.

Preload y prefetch

Estas técnicas ayudan a adelantar recursos críticos o probables, pero deben usarse con moderación. Un mal uso puede aumentar bytes descargados en vez de optimizarlos.

Minificación y compresión

Reducir peso de JS, CSS y HTML sigue siendo una práctica básica, aunque a veces se olvida frente a debates más sofisticados.

Optimización de consultas

En SQL, la consulta correcta vale más que la máquina más cara. En D1, además, una consulta mal indexada lee más filas y puede aumentar factura y latencia al mismo tiempo.[page:1]

Optimización de imágenes

La imagen más barata es la que mantiene calidad suficiente con el menor tamaño posible y se entrega desde caché cuando es viable.

Comparativa económica

Esta sección presenta estimaciones aproximadas para una plataforma educativa de 50,000 usuarios. No representan una cotización contractual y dependen fuertemente del patrón real de uso, lecturas, sesiones, tráfico de archivos, correo y frecuencia de acceso. Se basan en la documentación oficial consultada y en supuestos razonables para comparar modelos, no para sustituir una calculadora de producción.[page:1][page:2][web:182][web:198][web:191]

Supuestos comparativos

Para mantener coherencia, se asume mensualmente algo parecido a:

  • 50,000 usuarios registrados.
  • 15,000 usuarios activos frecuentes.
  • frontend web público + panel autenticado.
  • 8 millones de requests dinámicos.
  • 200 GB de archivos almacenados.
  • 1 TB de salida de archivos públicos/semipúblicos.
  • 60 millones de lecturas de datos al mes.
  • 8 millones de escrituras ligeras al mes.
  • 500,000 correos transaccionales al mes.

Estos supuestos solo sirven para visualizar órdenes de magnitud y decisiones arquitectónicas.

Solo Cloudflare

Un escenario mayoritariamente Cloudflare podría usar Pages, Workers, D1, R2 y quizá otros primitives. Bajo estos supuestos:

  • Workers probablemente quedaría cerca del mínimo base o ligeramente por encima si el frontend está bien cacheado, porque 8 millones de requests dinámicos aún caben dentro de los 10 millones incluidos del plan Paid, siempre que el CPU consumido no exceda demasiado los 30 millones de ms incluidos.[page:1]
  • R2 costaría por almacenamiento y operaciones, pero no por 1 TB de egreso, lo cual es una ventaja enorme.[page:1]
  • D1 probablemente sería muy barato si el modelo de consultas está bien indexado, porque 60 millones de filas leídas al mes está muy por debajo de los 25 mil millones incluidos, mientras que 8 millones de filas escritas seguirían dentro de los 50 millones incluidos.[page:1]

En términos cualitativos, esta arquitectura tiende a ser de costo bajo a moderado, con muy buena eficiencia cuando el producto encaja bien en primitives edge y SQL ligero.

Solo Firebase

Un escenario solo Firebase podría usar Hosting, Authentication, Firestore, Cloud Storage, Cloud Functions y Analytics. Aquí el resultado depende muchísimo del patrón de lectura. Firestore y Storage pueden escalar muy bien funcionalmente, pero su costo puede crecer rápido si el modelado induce demasiadas lecturas repetidas o mucho tráfico de archivos descargados fuera de caché.[page:2]

Firebase Hosting cobra transferencia tras superar el nivel gratuito, y Cloud Storage depende del tipo de bucket y de tarifas de Google Cloud, por lo que una plataforma con mucha descarga de archivos puede volverse más costosa que una arquitectura basada en R2 para binarios pesados.[page:2]

En términos cualitativos, esta opción tiende a ser de costo moderado a alto si el sistema es intensivo en lecturas y archivos, aunque ofrece una excelente velocidad de desarrollo.

Solo AWS

Un escenario solo AWS podría usar S3, Lambda, CloudWatch, SES, quizá RDS o servicios complementarios. AWS es muy flexible, pero su complejidad operativa y de facturación suele ser mayor. S3 y Lambda funcionan muy bien, pero el costo total depende mucho de transferencia, logs, observabilidad y diseño detallado.[web:182][web:142][web:197]

En términos cualitativos, esta opción tiende a ser de costo moderado a alto, con la mejor amplitud de servicios, pero también con mayor necesidad de disciplina arquitectónica para no dispersar gasto.

Arquitectura híbrida Cloudflare + Firebase + AWS

La arquitectura híbrida usa cada proveedor donde más conviene:

  • Cloudflare para frontend, edge, DNS, WAF, CDN y archivos públicos frecuentes con R2.[web:171][page:1]
  • Firebase para Authentication y, en algunos casos, módulos donde Firestore aporta mucha velocidad de desarrollo.[page:2]
  • AWS para SES y Polly cuando correo y voz son realmente necesarios.[web:197]

Esta arquitectura suele ser la más sensata para proyectos educativos complejos porque evita usar una sola plataforma para todo. Bien diseñada, tiende a tener costo moderado, mejor equilibrio entre rendimiento y flexibilidad y menor riesgo de pagar caro por usar un servicio fuera de su punto fuerte.

Tabla comparativa cualitativa

Opción Costo mensual aproximado Costo anual aproximado Complejidad Escalabilidad Mantenimiento Seguridad
Solo Cloudflare Bajo a moderado [page:1] Bajo a moderado [page:1] Media [web:171] Alta para edge, frontend y archivos [web:171][page:1] Bajo a medio [web:181] Alta en perímetro y red [web:171]
Solo Firebase Moderado a alto [page:2] Moderado a alto [page:2] Baja a media [page:2] Alta, pero sensible al patrón de lecturas y storage [page:2] Bajo al inicio, medio al crecer [page:2] Buena, muy dependiente de reglas y modelado [page:2]
Solo AWS Moderado a alto [web:182][web:142][web:197] Moderado a alto [web:182][web:142][web:197] Alta [web:142] Muy alta [web:182] Medio a alto [web:142] Muy alta, pero más operativa [web:142]
Híbrida Moderado [page:1][page:2][web:197] Moderado [page:1][page:2][web:197] Media a alta [web:171][page:2] Muy alta [web:171][page:2] Medio [web:171][web:199] Muy alta si se definen fronteras claras [web:171][web:199]

Casos reales

elprofe.org

Un sitio como elprofe.org probablemente se beneficia de una arquitectura fuertemente estática o semiestática, con Pages, caché perimetral y muy poca lógica dinámica. Aquí la optimización real no viene de “más backend”, sino de mantener assets ligeros, contenido bien cacheado y formularios aislados en endpoints específicos.

NLink encaja especialmente bien en Cloudflare porque su núcleo son redirecciones rápidas, analytics y administración ligera. Workers + D1 + Pages forman una combinación muy eficiente cuando el lookup está bien indexado y el tráfico público está optimizado.[page:1][web:181]

Credenciales Digitales

Este caso suele requerir mezcla: auth, metadata, archivos, validación pública, QR y correo. Optimizar costos aquí implica no poner todo en el mismo servicio, separar panel y validación, usar R2 para binarios y reservar Firestore o D1 para la metadata correcta.

Master Finanzas

Si se trata de contenido, usuarios, materiales y automatizaciones moderadas, la arquitectura híbrida suele dar mejor equilibrio entre costo y crecimiento. El error común sería sobredimensionar IA, video o procesos pesados antes de tener demanda real.

Sistema Escolar

Un sistema escolar completo exige especial cuidado en consultas, archivos, notificaciones y auditoría. El gasto suele crecer no por un servicio aislado, sino por la suma de pequeñas ineficiencias repetidas miles de veces.

IA El Profe

En plataformas de IA, el costo puede dispararse si cada prompt hace demasiadas búsquedas, demasiadas consultas o demasiada inferencia. Optimizar aquí implica reducir contexto, cachear resultados útiles, controlar historial y usar almacenamiento de documentos de forma ordenada.

Estrategias profesionales

MVP

Un MVP no debe diseñarse como si ya tuviera un millón de usuarios. Debe diseñarse para aprender rápido y gastar poco, sin cerrarse puertas.

Escalar por etapas

Cada etapa debe justificar el siguiente nivel de complejidad. Si un sistema aún no necesita colas, multi-base o observabilidad avanzada, agregarlo demasiado pronto puede ser un desperdicio.

Pago por uso

El pago por uso es una ventaja solo si el patrón de uso está optimizado. De lo contrario, se convierte en un espejo roto: parece barato al principio y luego castiga cada mala decisión.

Optimización continua

Optimizar costos no es un evento único. Debe revisarse mensualmente:

  • qué rutas consumen más,
  • qué archivos se descargan más,
  • qué consultas escanean demasiado,
  • qué correos son innecesarios,
  • qué paneles hacen lecturas repetidas.

No sobredimensionar

Comprar arquitectura imaginaria para usuarios que aún no existen es una de las formas más comunes de desperdiciar dinero.

No comprar infraestructura innecesaria

Si un sitio puede vivir con Pages y formularios ligeros, no necesita una gran capa de backend. Si un módulo es eventual, quizá no necesita una base dedicada todavía.

Cuándo migrar de plataforma

Se migra cuando la arquitectura actual ya no resuelve bien la relación entre costo, rendimiento, mantenimiento y riesgo. No se migra por moda.

Diagramas ASCII

Escalabilidad

100 usuarios
   |
   v
Arquitectura simple
   |
   v
1,000 usuarios
   |
   v
Métricas + caché + separación básica
   |
   v
10,000 usuarios
   |
   v
Índices + observabilidad + rutas críticas
   |
   v
100,000 usuarios
   |
   v
Modularidad + rate limiting + auditoría
   |
   v
1,000,000 usuarios
   |
   v
Desacoplamiento fuerte + procesos asíncronos + control fino de costos

Alta disponibilidad

           +----------------+
           |    Usuario     |
           +-------+--------+
                   |
                   v
          +-------------------+
          | Cloudflare Edge   |
          +----+---------+----+
               |         |
               v         v
          +--------+ +--------+
          | Ruta A | | Ruta B |
          +---+----+ +---+----+
              |          |
              +----+ +---+
                   v v
               +-------+
               | Datos |
               +-------+
                 /   \
                /     \
               v       v
          Backup    Réplica

Arquitectura modular

Frontend (Pages)
      |
      +---- API pública (Workers)
      |
      +---- Auth (Firebase)
      |
      +---- SQL (D1)
      |
      +---- Archivos (R2)
      |
      +---- Correo (SES)
      |
      +---- Analytics / Logs

Flujo de costos

Usuario
  |
  v
Request dinámico ------> CPU ------> costo compute
  |
  +----> DB reads ------> costo datos
  |
  +----> File download -> costo storage / transfer
  |
  +----> Email ---------> costo notificación
  |
  +----> Logs ----------> costo observabilidad

Optimización

Sin optimizar:
Usuario -> Worker -> DB -> Storage -> Respuesta

Optimizado:
Usuario -> CDN/Cache -> Respuesta
             |
             +--> Worker solo si hace falta
                     |
                     +--> DB indexada
                     +--> Storage optimizado

Buenas prácticas

  • Medir antes de optimizar.
  • Diseñar para la etapa actual y la siguiente, no para una fantasía lejana.
  • Separar claramente tráfico público y administrativo.
  • Cachear todo lo cacheable.
  • Usar índices donde realmente reducen scans.[page:1]
  • Revisar facturación cada mes, no solo cuando aparece un problema.
  • Minimizar lecturas repetidas en Firestore.[page:2]
  • Servir archivos pesados desde una capa preparada para ello, no desde un endpoint improvisado.
  • Mantener secretos fuera del código.
  • Establecer alertas de consumo y error.

Errores comunes

  • Diseñar como si ya hubiera 1 millón de usuarios cuando apenas hay 100.
  • No instrumentar métricas desde el inicio.
  • Tratar almacenamiento como si solo cobrara por GB y olvidar operaciones y transferencias.
  • Ignorar el costo de logs y monitoreo.[web:142]
  • Usar Firestore con patrones de lectura derrochadores.[page:2]
  • Crear Workers para todo, incluso cuando un asset estático bastaría.[page:1]
  • No optimizar imágenes y luego culpar al proveedor por la factura.
  • Elegir una sola plataforma por apego emocional en vez de por responsabilidad técnica.

Curiosidades

  • Cloudflare Workers no cobra subrequests hechos desde un Worker como requests adicionales de entrada, lo cual favorece ciertas composiciones internas bien diseñadas.[page:1]
  • D1 no cobra egreso ni compute adicional propio; el cobro principal se centra en filas leídas, filas escritas y almacenamiento.[page:1]
  • R2 elimina el cargo de egreso a Internet, lo que lo vuelve especialmente atractivo para bibliotecas de archivos con alto consumo público.[page:1]
  • GitHub Enterprise Cloud incorpora controles como SAML, audit log streaming e IP allow list, recordando que la seguridad operativa también forma parte del costo total de una arquitectura madura.[web:199]
  • Google Workspace no es solo correo; en proyectos educativos e institucionales puede representar una línea presupuestal relevante si el número de cuentas crece, especialmente entre Business Starter y Business Standard.[web:191]

Resumen

Diseñar infraestructura profesional no consiste en usar más servicios, sino en usar los servicios correctos en el momento correcto. La escalabilidad real exige equilibrio entre rendimiento, disponibilidad, seguridad y costo.

Las arquitecturas modernas permiten empezar pequeño y crecer mucho, pero esa promesa solo se cumple si el sistema se observa, se modela bien y se optimiza continuamente. Una mala consulta, una mala estrategia de archivos o una mala decisión de caché pueden costar más que una tecnología completa bien elegida.

Cloudflare, Firebase, AWS, GitHub y Google Workspace no son solo herramientas aisladas. Son piezas de un presupuesto vivo. Entender cómo cobran, qué optimizan y qué castigan es parte del oficio de construir sistemas sostenibles.

Glosario

  • Escalabilidad: capacidad de crecer sin degradación grave ni gasto descontrolado.
  • Elasticidad: capacidad de ajustar consumo a la demanda real.
  • Alta disponibilidad: capacidad de seguir operando pese a fallos parciales.
  • Escalabilidad vertical: crecer aumentando recursos de una sola unidad.
  • Escalabilidad horizontal: crecer agregando múltiples unidades.
  • Failover: cambio automático o asistido hacia un recurso alterno cuando uno falla.
  • CDN: red de distribución de contenido.
  • Cache: almacenamiento temporal de respuestas o recursos para evitar recomputación.
  • CPU time: tiempo efectivo de cómputo facturable en ciertos runtimes.[page:1]
  • Rows read / rows written: unidades de facturación de D1 basadas en filas leídas o escritas.[page:1]
  • Class A / Class B: categorías de operaciones de R2, donde Class A suele mutar estado y Class B suele leerlo.[page:1]
  • MAU: monthly active user; usuario activo mensual.[page:2]
  • Invocación: ejecución de una función o servicio bajo demanda.[page:2][web:182]
  • Egress: tráfico saliente hacia Internet u otros destinos.
  • Observabilidad: capacidad de entender el estado del sistema mediante logs, métricas y trazas.
  • Brotli: algoritmo de compresión orientado a assets web.
  • WebP / AVIF: formatos de imagen optimizados para la web.
  • Rate limiting: limitación de frecuencia de solicitudes.
  • Audit log: registro verificable de acciones relevantes.[web:199]

20 preguntas de autoevaluación

  1. ¿Qué significa realmente escalar una aplicación?
  2. ¿En qué se diferencian crecimiento y escalabilidad?
  3. ¿Qué ventajas tiene la escalabilidad vertical y cuándo deja de ser suficiente?
  4. ¿Qué ventajas y riesgos introduce la escalabilidad horizontal?
  5. ¿Por qué alta disponibilidad no es lo mismo que backup?
  6. ¿Qué cambia arquitectónicamente entre 100 y 10,000 usuarios?
  7. ¿Qué cambia entre 10,000 y 100,000 usuarios?
  8. ¿Cuándo conviene seguir con un monolito y cuándo desacoplar módulos?
  9. ¿Qué papel cumplen APIs, eventos y colas en el crecimiento del sistema?[page:1]
  10. ¿Por qué la caché es una de las optimizaciones más rentables?
  11. ¿Cómo impactan los índices en costo y rendimiento de D1?[page:1]
  12. ¿Por qué Firestore puede ser muy cómodo pero también caro si se modela mal?[page:2]
  13. ¿Qué ventajas económicas ofrece R2 para archivos públicos frecuentes?[page:1]
  14. ¿Cómo se interpreta una línea de CPU time en una factura?[page:1][web:182]
  15. ¿Qué diferencias importantes existen entre la facturación de Cloudflare, Firebase y AWS?[page:1][page:2][web:182]
  16. ¿Por qué monitoreo y alertas son parte del costo total del sistema?[web:142]
  17. ¿Qué errores comunes disparan facturas innecesarias?
  18. ¿Cuándo conviene usar una arquitectura híbrida?
  19. ¿Qué señales indican que ya es momento de migrar o introducir un nuevo servicio?
  20. ¿Cómo justificarías económicamente una arquitectura para 50,000 usuarios sin inventar cifras exactas?

Proyecto práctico

El proyecto práctico consiste en diseñar el presupuesto aproximado de una plataforma educativa nacional y proponer un plan de crecimiento tecnológico y financiero para cinco años. Todas las cifras siguientes son aproximadas, no contractuales, y dependen del patrón real de uso, del tipo de archivo, de la frecuencia de acceso, del diseño de datos y de la región de cada servicio.[page:1][page:2][web:182][web:191]

Supuestos base del proyecto

Se asumirán cuatro escenarios de escala:

  • 1,000 usuarios registrados.
  • 10,000 usuarios registrados.
  • 50,000 usuarios registrados.
  • 100,000 usuarios registrados.

Y un patrón creciente de uso en frontend, autenticación, consultas, archivos y correos transaccionales.

Escenario 1: 1,000 usuarios

En esta etapa, una arquitectura con fuerte presencia de niveles gratuitos o mínimos de pago suele ser suficiente. Cloudflare puede operar con costos muy bajos si el tráfico dinámico cabe dentro de los límites incluidos y los assets estáticos dominan la experiencia.[page:1][web:181]

Firebase también puede ser competitivo aquí gracias a sus límites gratuitos para Firestore, Functions, Hosting y Authentication, siempre que el uso real siga siendo moderado.[page:2]

AWS suele ser menos atractivo como arquitectura única en esta escala si el equipo quiere minimizar complejidad operativa, aunque servicios puntuales como SES pueden seguir teniendo sentido.[web:197]

Escenario 2: 10,000 usuarios

Aquí empiezan a verse los costos reales. Ya conviene monitorear:

  • lecturas por usuario,
  • volumen de archivos,
  • costo por envío de correo,
  • invocaciones de backend,
  • crecimiento de logs.

Una arquitectura híbrida suele empezar a dar mejores resultados porque permite mover binarios y contenido público a R2, mantener identidad en Firebase y usar correo especializado si el volumen lo exige.[page:1][page:2][web:197]

Escenario 3: 50,000 usuarios

En este punto se vuelve indispensable separar costo por módulo:

  • frontend público,
  • paneles internos,
  • autenticación,
  • datos académicos,
  • archivos,
  • notificaciones,
  • observabilidad.

La arquitectura híbrida suele ser la más sana porque evita pagar caro por usar una sola plataforma fuera de su punto fuerte.

Escenario 4: 100,000 usuarios

Ahora la gobernanza tecnológica es tan importante como el presupuesto. Deben existir:

  • alertas financieras,
  • observabilidad por servicio,
  • límites de abuso,
  • revisión continua de consultas,
  • revisión de archivos fríos y calientes,
  • auditoría de integraciones externas.

Tabla orientativa del proyecto

Escala Cloudflare Firebase AWS Híbrida
1,000 usuarios Muy bajo si domina estático y uso ligero [page:1][web:181] Bajo si se aprovechan cuotas gratuitas [page:2] Bajo a moderado, pero con más complejidad [web:182][web:142] Bajo [page:1][page:2]
10,000 usuarios Bajo a moderado [page:1] Moderado si aumentan lecturas y storage [page:2] Moderado [web:182][web:142][web:197] Bajo a moderado [page:1][page:2][web:197]
50,000 usuarios Moderado [page:1] Moderado a alto [page:2] Moderado a alto [web:182][web:142][web:197] Moderado [page:1][page:2][web:197]
100,000 usuarios Moderado si el edge y caché están bien diseñados [page:1] Alto si persisten patrones costosos de lectura/archivo [page:2] Moderado a alto con buena optimización [web:182][web:142] Moderado y generalmente más equilibrado [page:1][page:2][web:197]

Plan de crecimiento a cinco años

Año 1

Objetivo: lanzar con el menor costo razonable.

  • Frontend optimizado.
  • Servicios administrados.
  • Métricas mínimas.
  • Nada de infraestructura sobredimensionada.

Año 2

Objetivo: medir y corregir.

  • Identificar rutas caras.
  • Afinar consultas.
  • Optimizar almacenamiento y correo.
  • Formalizar backups y alertas.

Año 3

Objetivo: desacoplar lo que ya demostró ser cuello de botella.

  • Separar módulos pesados.
  • Introducir colas o procesos asíncronos cuando haga falta.[page:1]
  • Ajustar observabilidad financiera.

Año 4

Objetivo: escalar con control.

  • Mejorar auditoría.
  • Refinar gobernanza de accesos.
  • Clasificar almacenamiento caliente y frío.
  • Revisar costos institucionales complementarios como repositorios, acciones CI/CD y cuentas colaborativas.[web:199][web:191]

Año 5

Objetivo: madurez financiera y técnica.

  • Costeo por módulo o por cliente.
  • Revisión de proveedores por especialidad.
  • Optimización continua basada en datos.
  • Introducción solo de servicios que justifiquen claramente su valor.

¿Cuándo conviene migrar o incorporar nuevos servicios?

  • Cuando el costo de mantener la arquitectura actual supera el costo de mover una parte de ella.
  • Cuando un módulo necesita un patrón de acceso distinto al actual.
  • Cuando la seguridad o la auditoría exigen capacidades que no estaban previstas.
  • Cuando el crecimiento vuelve ineficiente seguir usando una sola tecnología para todo.

Lección final del proyecto

El presupuesto de una plataforma nacional no se controla comprando la opción aparentemente más barata. Se controla diseñando bien, midiendo a tiempo y asignando cada responsabilidad al servicio que mejor resuelve su patrón real de uso. Esa es la diferencia entre una app que sobrevive y una app que sangra dinero silenciosamente.