Si bien las arquitecturas serverless pueden ser extremadamente útiles para resolver algunos problemas, tienen un cierto nivel de complejidad, especialmente cuando involucran una ejecución y flujo de datos no triviales a través de múltiples Lambdas interdependientes – esto a veces puede resultar en una arquitectura Lambda pinball. Nuestros equipos han observado que mantener y probar las arquitecturas de Lambda pinball puede ser un gran desafío: entender la infraestructura, el despliegue, el diagnóstico y la depuración puede volverse difícil. A nivel de código, el mapeo simple entre los conceptos de dominio y las múltiples Lambdas involucradas es prácticamente imposible, lo que hace que cualquier cambio y añadidura sea un desafío. Si bien creemos que la tecnología serverless es la opción adecuada para algunos problemas y dominios, no es una "solución milagrosa" para todos los problemas, por lo que debe tratar de evitar el Lambda pinball. Un patrón que puede ayudar es establecer una distinción entre interfaces públicas y publicadas y aplicar límites de dominio con interfaces publicadas entre ellas.
Llevamos ya un par de años construyendo arquitecturas serverless en nuestros proyectos y hemos notado que es muy fácil caer en la trampa de construir un monolito distribuido. Las arquitecturas Lambda pinball característicamente suelen perder de vista la lógica de dominio importante entre tanto enredo de Lambdas, buckets y colas, a medida que las solicitudes de estas rebotan, se incrementa entonces la complejidad de los gráficos en los servicios en la nube. Usualmente, es complicado testearlas como unidades, y las necesidades de la aplicación deben ser testeadas como un todo integrado. Un patrón que podemos utilizar para prevenir estas arquitecturas de pinball es diferenciar entre interfaces públicas y publicadas y aplicar límites de dominio con interfaces publicadas entre ellas.
