Escoger la arquitectura correcta

Ayer en Ecuador se iba a dar acceso a una página web para registrarse para recibir la vacuna en contra de COVID-19 planvacunarse.ec, si eres de Ecuador probablemente ya sabes lo que pasó después, la página paso caída todo el día.

El tema me pareció interesante traerlo en esta publicación primero porque es de interés nacional y segundo porque cada día la tecnología afecta más y más a nuestras vidas y la de todos los que nos rodean.

Personalmente pienso que la vacunación no debía haberse hecho con registro previo, uno porque el acceso a esta opción está restringiendo a mucha gente que no tiene Internet, computadora y conocimientos para usar la página web; y dos creo que el gobierno debería saber lo suficiente de todos sus habitantes vía registro civil, IESS, escuelas, etc. como para hacer un listado y publicar el listado de las personas elegibles en cada fase.

Si no era una opción hacerlo de esa forma, ahora sí vamos a la parte técnica que también deja mucho que desear.

No tengo todos los requerimientos que debe cumplir el sistema de registro para vacunas, pero vamos a asumir los siguientes requerimientos funcionales:

Requerimiento informativo:

Como usuario visitante de planvacunarse.ec
Debo poder leer la información acerca de las fases de la vacunación
Para poder estar informado y saber cuando me va a tocar el turno.

Requerimiento de registro:

Como usuario visitante de planvacunarse.ec
Debo poder ingresar mi cédula de identidad
ingresar un email para recibir notificaciones
y contestar algunas preguntas médicas
Para poder quedar registrado y que me notifiquen
lugar y fecha de vacunación en un futuro.

Vamos a pretender que debemos diseñar un software que soporte estos requerimientos funcionales. Para un desarrollador junior es fácil tomar la herramienta que uso todos los días y hacer que cumpla estos dos requerimientos, en el caso de quien se encargó de esta página su herramienta fue wordpress para el sitio informativo y el plugin de formularios para el registro, funciona para algunos cientos de visitas concurrentes, dependiendo de las características del servidor, pero para millones de no-vacunados simplemente no.

Como arquitectos de software debemos hilar más fino y obtener requerimientos que no están expresados explícitamente en los anteriores, temas como: quiénes van a usar este software, desde qué plataformas, con qué tipos de red, a cuántas personas podemos dar servicio al mismo tiempo, cuál es el nivel de servicio mínimo esperado, etc. etc.

Escoger la arquitectura correcta se trata de analizar y tomar decisiones con todos los requerimientos explícitos e implícitos que el software debe tener. Es probable que las herramientas que tienes a disposición entren en conflicto con los requerimientos de la arquitectura y eso está bien, no siempre vas a poder usar las herramientas que te gustan o te sientes cómodo.

En mi opinión profesional este sitio de registro de vacunación debió haberse hecho con la siguiente arquitectura:

• Generador de sitios estáticos, como hugo, gatsby o nextjs. para satisfacer el primer requerimiento informativo. Esta opción tiene la ventaja de que puedes usar servicios de distribución de contenido y cache que han sido probados por empresas globales para servir sus sitios web. Servicios como AWS Cloudfront o Cloudfare son obligatorios en este tipo de ambientes en el que esperamos millones de visitantes al mismo tiempo. Dentro del mismo sitio estático se pudo haber tenido una aplicación de página única (single page application) para manejar el registro y usar una API hacia el backend para guardar la información.

• Funciones serverless, como AWS lambda o Serverless computing de google cloud para cumplir con el segundo requerimiento de registro. Esto permite tener flexibilidad a la hora de escalar la parte dinámica del sitio, como es recibir y guardar información para futuro. Este tipo de ambientes permiten recibir gran cantidad de tráfico sin manejar servidores.

• Y para la parte de guardar la información una base de datos SQL no tiene mucho sentido, ya que el requerimiento principal de guardar la información lo más rápido posible no es una característica de estas bases, para eso usaría una base mucho más eficiente como DynamoDB en AWS que está diseñada para manejar escalas de trillones de peticiones por día y 20 millones de peticiones por segundo. Es decir todo el Ecuador se pudo haber registrado sin problemas en poco tiempo.

Esto solo fue un experimento mental, estoy seguro que hay muchos más requerimientos internos como validar cédulas con el registro civil, validar emails, etc. Para la brevedad del artículo decidí dejarlos afuera. Por otro lado estoy seguro que haya otras herramientas con las que se puede construir una arquitectura correcta, ustedes que hubieran usado?

Puedes contestarme registrandote y contestando al e-mail de bienvenida.