En muchos artículos, incluidos muchos de los que hemos escrito, se acaba haciendo un poco de «autobombo» sobre las bondades de un proceso o de un equipo. Pero no sólo de los éxitos se aprende, también de los errores, ¡y mucho! Así que hoy te invitamos a un recorrido por parte de nuestra arquitectura y nuestras mejoras a través de un error (o dos, o tal vez tres, bueno, unos cuantos). Acompáñanos.

En Frogtek desarrollamos Tiendatek, una aplicación para Android que sirve como TPV. Para buscar ese valor añadido tenemos un botoncito en la aplicación que dirige al usuario a una web (con un webview) donde podrá obtener mucha más información sobre su stock, mejores productos, histórico, … Además tenemos una serie de APIs para usos diversos. Perdone, estamos en el 2016, si no expones una API para registrar las veces que uno va al servicio no eres nadie. Pues eso, servicios varios, que digamos, usa toda la empresa de una forma o de otra (no, lo de ir al baño no está implementado).

Comienza la historia: la motivación del cambio

Medir y mejorar tiempos de respuesta. Fin de la sección.

Hace unas semanas desplegamos una prueba de concepto para monitorizar y mejorar la forma en la que estaba expuesto un servicio. Lo que nosotros llamamos «el pedido sugerido». Al final siempre hay rincones del código y de nuestra infraestructura que reciben menos mimo del que merecerían. Y este era un claro ejemplo. ¿Un servicio con una tasa de errores del en torno al 7-8%? Un poco de chapa y pintura y ya lo tenemos en torno al 1-2% (principalmente timeouts por un socket que cierran los clientes impacientes).
Seguir leyendo