Diseñar el backend de una aplicación como una billetera digital usando funciones serverless implica decisiones arquitectónicas muy distintas a las de servidores tradicionales o contenedores. Comprender cómo se enrutan las peticiones, cómo se conectan las bases de datos y cuánta concurrencia reservar puede marcar la diferencia entre una aplicación rápida y una que colapsa bajo carga.
¿Cómo se estructura un backend basado en funciones serverless?
El flujo comienza igual que en cualquier arquitectura web: el usuario llega a través del DNS, pasa por una capa de CDN más WAF y llega al API Gateway. La diferencia está en lo que ocurre después. En lugar de un servidor monolítico o un clúster de contenedores, cada ruta del API dispara una función independiente [01:40].
- El path
/saldos activa la función de consulta de saldos.
- El path
/pagos ejecuta la función de pagos.
- El path
/cash-in invoca la función de recarga.
Incluso en la capa de CDN ya es posible ejecutar funciones serverless, por ejemplo para transformar un request o realizar redireccionamientos 301 o 302 (permanentes o temporales) antes de que la petición llegue al backend [01:12].
¿Qué tipo de base de datos conviene en una arquitectura serverless?
Cuando cada función accede a su propia tabla, una base de datos llave-valor (no relacional) encaja de forma natural porque no requiere gestionar conexiones persistentes [03:26]. Cada función consulta o registra datos de manera independiente.
Sin embargo, si se necesita una base de datos relacional como MySQL, aparece un problema crítico: múltiples funciones abriendo conexiones simultáneas pueden agotar el límite y tumbar la base de datos. Para resolver esto, los cloud providers ofrecen un proxy de base de datos que se ubica entre la capa de aplicación y la base de datos [04:10].
Este proxy aporta tres beneficios concretos:
- Seguridad: garantiza comunicación cifrada con TLS.
- Gestión de conexiones: maneja el borrowing (préstamo de canales de conexión).
- Failover más rápido: ante la caída de la instancia maestra, el cambio a la standby apenas pierde un paquete.
¿Qué es la concurrencia reservada y por qué importa?
Cada cloud provider establece un límite global de concurrencia para todas las funciones de una cuenta. Por ejemplo, en AWS ese límite por defecto es de mil ejecuciones por segundo [07:00]. Si no se planifica, una función poco prioritaria podría consumir capacidad que necesitan los servicios críticos.
La concurrencia reservada permite asignar capacidad fija a las funciones más importantes [06:20]. Si se reservan 200 ejecuciones por segundo para pagos y 200 para saldos, quedan 600 que se reparten dinámicamente entre el resto de servicios: cashout, generación de QR, términos y condiciones, entre otros.
- Se prioriza lo que más usa el usuario: consultar saldo y realizar pagos.
- El restante se distribuye bajo demanda entre funciones menos frecuentes.
- Si la carga crece, se puede solicitar al proveedor un aumento; en casos reales se ha escalado hasta veinte mil ejecuciones por segundo [08:24].
¿Qué consideraciones operativas no se pueden ignorar?
El orquestador de funciones es indispensable cuando una función depende de otra o necesita encadenar pasos. En AWS existe Step Functions; en otros entornos se ha usado Apache Airflow como alternativa válida, aunque conviene evaluar pros y contras [05:30].
Otras consideraciones operativas clave:
- Cada función debe tener su propio flujo de CI/CD desde un repositorio dedicado [09:00].
- Definir si la función corre dentro de una VPC: si es así, hay que asegurar suficientes direcciones IP disponibles para la cantidad de ejecuciones concurrentes [09:20].
- El cold start puede agregar hasta tres segundos de latencia en el primer arranque de la función [09:36].
¿Cuándo conviene una arquitectura híbrida en lugar de solo funciones?
El cold start es el factor decisivo. Si un servicio crítico como pagos no puede tolerar esos segundos de espera inicial, porque el usuario cancelaría la transacción, la solución es una arquitectura híbrida [09:50]. Pagos podría ejecutarse en Kubernetes con latencia predecible, mientras que consultas de saldo y cash-in se mantienen en funciones serverless donde la latencia inicial es aceptable.
Lo verdaderamente valioso es tener criterio para elegir entre servidores, contenedores y funciones según las necesidades reales de cada servicio. No existe una única respuesta correcta: la mejor arquitectura es la que combina estos componentes entendiendo sus particularidades. ¿Ya identificaste cuáles servicios de tu aplicación podrían beneficiarse de funciones serverless y cuáles necesitan otra estrategia?
