¿Cómo debo crear mi aplicación web, una API para login, otra para registro y otra para funcionalidad?

Hola.

Así como lo pones en tu pregunta, estás describiendo más o menos lo que es una arquitectura de microservicios.

La imágen la saqué de la intruducción de microservicios de nginx 

En esencia, tienes dos tipos de arquitecturas: la llamada monolítica y la de microservicios.

Así se ve la monolítica:

Así como preguntas, la API de login y registro estarían en el microservicio de gestión de usuarios, que sirve a los demás servicios, que tú llamarías funcionales. El cliente convive solo con una entrada, el gateway, e internamente ya es como se llaman unos servicios a otros, de forma invisible para los clientes, pero claro, esto queda a criterio del diseño del sistema, ya que también puedes publicar APIs por separado, incluso con versiones.

Cada arquitectura tiene sus pros y contras.

Como ves en la primera imagen cada servicio tiene su API, mientras que en uno monolítico solo existe una universal.

Tener un API por servicio resulta más cómodo al momento de dar mantenimiento, ya que están pensados en ser específicos y simples, aunque también introduces una nueva capa de complejidad en tu sistema, pues necesitas comunicación entre un servicio y otro.

Dependiendo de cómo administres tu sistema, puede que tengas que llamar a tus APIs entre servicios, o usar un broker, como llamaría el sistema Moleculer, que automatiza la comunicación entre servicios para facilitar la vida del desarrollador.

Sin embargo, el sistema de microservicios introduce sus propios desafíos de diseño. Por ejemplo, ya no haces solo un schema de base de datos, sino que haces uno por servicio para asegurar un "emparejamiento holgado" y pues nunca depender de un solo nodo por diseño para nada. Pero también eso puede complicar interacciones más complejas, como si tienes que alterar varios servicios en un mismo proceso. Lo bueno es que todo tiene "su modo", y usando una utilería adecuada, se pueden compensar un poco estos desafíos.

Otro desafío es el que un mal diseño de microservicios puede joder buena parte de sus ventajas, como en el API gateway, bien puede ayudar para encapsular todo el sistema (bueno) o puede servir como un cuello de botella, obligando a los clientes digamos también a conocer el servicio subyaciente porque no es lo suficientemente completo (malo).

Ya que mi mundo es en Node.js, hablaré en esos términos. Usando librerías populares como Express o Fastify, puedes crear tú solito tus microservicios también. Tampoco es que requieras infraestructura especializada. De hecho, también puedes combinar un toolkit como Moleculer o Seneca con Express, Fastify u otros, pero bueno, no quiero hacer que de vueltas tu cabeza jaja.

Además, en un sistema de microservicios sueles requerir tecnología de transportador o mensajería, que ayuda a diversas tareas de manejo de carga entre servicios. Algunos son NATS, ZeroMQ, RabbitMQ, Kafka o incluso Redis, donde todos utilizan un sistema llamado pub/sub (entre otros) y tienen sus diferencias. Pero bueno, eso ya es otro tema y sueles preocuparte por esto más bien cuando ya tienes un sistema grande. Cabe decir que la mayoría de sistemas de mensajería utilizan sus propios protocolos, donde el más común es el TLS, pero por ejemplo NATS utiliza su propio protocolo nats:// también.

Ya me ando desviando…

Bueno, vale la pena considerarlos en tu aplicación. En un sistema monolítico, como el API es único, si se jode pues todo el API se cae. Es un todo o nada.

En uno de microservicios es diferente. Si un sistema se cae, los demás pueden seguir funcionando. Entonces entra la pregunta, ¿qué pasa con las solicitudes que llegan al sistema caído?

Imagina que el sistema de pagos de un tercero se cae, ¿qué pasa con todas las solicitudes de pago en la e-tienda?

Aquí es donde se ven realmente los beneficios del sistema de mensajería que utilices y su configuración, pues puede que se las solicitudes se pierdan, o puede que entren en un queue y se sirvan efectivamente cuando el sistema vuelva en línea. Puede incluso ese queue caducar los mensajes en 10 minutos o persistirlos en el disco indefinidamente hasta que se consuman, dependiendo de la solución que utilices.

Esto hace tu sistema más resistente a fallos, además de tener beneficios extras de balanceo de cargas.

Moleculer por ejemplo, introduce también un módulo de tolerancia de fallos, al administrar sus recursos automáticamente (bajo configuración) para no desperdiciar recursos mandando solicitudes a un sistema caído. Mientras, también, busca re-conectarse automáticamente.

En un sistema monolítico no te sueles precupar tanto por estos temas, pero a la vez tu aplicación es menos flexible, ya que en uno de microservicios, por ejemplo, si un servicio se usa el triple que otro, puedes escalar ese individualmente con facilidad (a través de Docker o Kubernetes) logrando también un sistema más rápido ya que tienes un mismo API triplicado, cada uno procesando pedidos al ritmo que el sistema de mensajería le de para su uso óptimo, incluyendo el balanceo de cargas, mientras que en uno monolítico, puede ser más complicado, ya que solamente puede aventar más recursos en general o crear configuraciones mucho más específicas.

Otra ventaja importante es que no solo se trata de aventar recursos a los servicios adecuados, sino que mientras unos servicios pueden ser más intensivos en CPU y otros en memoria RAM, puedes desplegar cada uno en el servicio adecuado de tu proveedor, quedándole cada uno como traje de buzo, sin tener que sacrificar nada como harías con un sistema monolítico.

Me tomo el tiempo de explicar esto porque en cursos es raro oír de estos temas del mundo real, ya que prácticamente todo se enfoca a la arquitectura monolítica, que es más cómoda para el principiante

Cabe señalar que muchos sistemas comienzan como monolíticos y luego se migran a los multiservicios, pero eso implica un costo de reingeniería en tiempo y dinero.

Si la respuesta te sirvió, agradezco tu voto positivo 👍.

¡Suerte!