En un mercado cada vez más competitivo y con un consumidor que está cada vez más informado, es necesario implementar sistemas que provean de información en tiempo real y de sistemas rápidos, por medio de un componente tecnológico. Escoger qué tecnologías utilizar en tu proyecto es una decisión que depende mucho de la situación en la que te encuentres. Comúnmente se tiene en cuenta el contexto de la compañía o el equipo, el conocimiento que ya hay en la organización y el objetivo estratégico tecnológico. En general, las organizaciones suelen ser conservadoras: mantienen el mismo lenguaje, el mismo framework subiendo la versión “major”, y las mismas pipelines de desarrollo. Esto permite a la compañía actualizarse reduciendo la inversión necesaria.
En estas decisiones, en ocasiones no se tiene en cuenta cuales son las necesidades de negocio implícitas en lo que llamamos Cross Functional Requirements (CFR). Los CFR definen cómo los sistemas se comportan, pero no qué hacen. El ejemplo más común de CFR es el “performance”: qué tan rápido funciona un sistema teniendo en cuenta los recursos a su alcance. Siempre hay discusiones de cuál tecnología o lenguaje es más rápido y usa menos recursos que otro.
Los equipos autónomos potencialmente son capaces de decidir qué tecnologías utilizar en base a los requisitos de negocio, a la visión técnica de la compañía, y de esta forma pueden aprovechar el esfuerzo de invertir en tecnología en positivo, con un objetivo claro. Este fue nuestro caso, al momento de trabajar con Holaluz. Holaluz es una compañía eléctrica de energía verde que diferencia su servicio, entre otros aspectos, ejerciendo de asesora energética, con el uso avanzado de tecnologías y datos. El valor diferencial es la capacidad de entender la información de consumo del cliente y los patrones para recomendar el mejor producto y una cuota que sea la más efectiva para los clientes. Debido a este modelo de negocio, la información que se provee a los clientes tiene que ser lo más precisa posible. Gracias a tener una visión clara, nuestro equipo en Thoughtworks España pudo entender el negocio e invertir en una tecnología que podía tener un impacto positivo: Reactor en Java.
Equipos de Thoughtworks y Holaluz
El producto en el que trabajamos es un sistema de comparativas de facturas que funciona de la siguiente manera: un comercial rellena la información correspondiente a una factura del cliente, mientras que el sistema le recomienda y le compara el mejor producto. Este proceso el comercial lo puede hacer en tiempo real: sea por teléfono o sea presencial, o en asíncrono, mientras toma un café va haciendo comparativas. El mercado de la energía es muy competitivo en España, por lo que asegurar una comparativa efectiva para convencer al cliente es importante. Si el sistema no respondiese, el comercial, para no perder la venta, le ofrecería otra comercializadora y nosotros perderíamos la venta.
La disponibilidad del sistema es crucial en estos casos, hay que responder al comercial y al cliente, sin importar la complejidad interna del sistema: que ahora depende de diversos microservicios donde cogemos información necesaria para generar la comparativa. Utilizar mecanismos de reintento, fallbacks y mitigación de riesgos es necesario para dar respuesta lo antes posible con la información más relevante. Y lo conseguimos de la siguiente forma:
Para cada producto que es válido de comparar, hacemos peticiones en asíncrono para recoger la información relevante y predicciones, y luego hacemos el cálculo de cuota (que potencialmente depende de otros sistemas adicionales). Para garantizar tiempos de respuesta, a cada una de las peticiones, le damos un ‘timeout’: es más importante responder, que responder con todo. Si uno de los sistemas no está disponible, al menos respondemos con lo que sí está disponible.
Con Reactor, hemos utilizado los operadores switchOnError, timeout, y zip para poder hacer todas estas operaciones en paralelo de forma reactiva, por lo que a nivel de rendimiento es bastante efectivo (95% de las peticiones se resuelven en menos de 200ms) y nuestra disponibilidad está de media en los 99.99%. Además, nos ha permitido desacoplar el cálculo de las cuotas de todo el flujo, por lo que añadir nuevos productos a las comparativas es simple y no afecta al rendimiento o la disponibilidad.
Gracias a ciertos patrones de desacople que nos permiten las tecnologías reactivas como Reactor o RxJava, ahora somos capaces de añadir nuevos productos, responder al cliente lo antes posible e impactar de forma positiva en la experiencia del comercial para hacer comparativas.
Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.
