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.