Detrás de cada reto, una decisión.

01Contexto y límites

Participación en el desarrollo de pagos en euros procedentes de Reino Unido en el contexto del Brexit, en la implementación de Bizum para una entidad bancaria y en la integración de fintechs del mismo grupo.

El flujo debía absorber un gran volumen de información y convivir con APIs externas que requerían comunicación síncrona.

Alcance: Desarrollo e integración dentro de un equipo; no se atribuye la creación del servicio completo a una sola persona.

02Fricción y riesgo

Una arquitectura asíncrona no resolvía por sí sola todos los intercambios: algunos pasos dependían de respuestas de terceros.

03Decisión y compromisos

Decisiones implementadas según el relato del responsable; la comparación explica sus funciones y compromisos.

El equipo eligió una arquitectura asíncrona con Kafka y microservicios implementados en Spring Boot. Se mantuvo comunicación síncrona allí donde las APIs de terceros lo exigían.

04Proceso e intervención

Procesar la información de pagos mediante Kafka → Implementar la lógica en microservicios Spring Boot → Integrar las APIs externas y afinar cada paso del flujo.

05Aprendizaje

Se alcanzó el objetivo previsto mediante ajustes sucesivos. El aprendizaje fue combinar el procesamiento asíncrono con las dependencias síncronas reales, en lugar de imponer un único patrón a todas las integraciones.

Base del relato: Relato de primera mano de Raúl Plaza, participante y responsable del contenido. Resultados cualitativos, sin métricas auditadas.

01Contexto y límites

Diseño de un hub de información médica que reúne citas, diagnósticos, encuentros asistenciales e información sobre pacientes y profesionales sanitarios.

El sistema debía absorber millones de datos al día y ofrecer acceso a aplicaciones externas. Ese volumen describe la necesidad del proyecto, no una medición auditada de rendimiento.

Alcance: Liderazgo tecnológico y diseño de la arquitectura, incluida una API de acceso a la información almacenada.

02Fricción y riesgo

Las necesidades evolucionaban: la plataforma tenía que incorporar cambios sin quedar limitada por su diseño inicial.

03Decisión y compromisos

Decisiones implementadas según el relato del responsable; la comparación explica sus funciones y compromisos.

Se eligieron microservicios con comunicación asíncrona para la ingesta y una API para las aplicaciones de terceros que necesitaban consultar la información.

04Proceso e intervención

Incorporar información clínica y asistencial → Procesarla mediante microservicios con comunicación asíncrona → Ofrecer acceso mediante API y evolucionar los módulos.

05Aprendizaje

La plataforma funciona y su arquitectura ha evolucionado con las necesidades del proyecto. La modularidad ha permitido introducir cambios respecto al diseño inicial. El aprendizaje es tratar la arquitectura como una estructura que evoluciona con el uso.

Base del relato: Relato de primera mano de Raúl Plaza, participante y responsable del contenido. Resultados cualitativos, sin métricas auditadas.

01Contexto y límites

Refactorización de partes de un producto de telemedida y diseño de la arquitectura de microservicios para canalizar datos de proveedores externos.

Los proveedores enviaban medidas a su propio ritmo; la plataforma debía ajustar su capacidad de ingesta a ese tráfico.

Alcance: Integración MQTT con proveedores externos de IoT y canalización de medidas eléctricas y de agua mediante microservicios y Kafka.

02Fricción y riesgo

Recibir un gran volumen de medidas requería coordinar la integración de entrada con el procesamiento interno.

03Decisión y compromisos

Decisiones implementadas según el relato del responsable; la comparación explica sus funciones y compromisos.

El equipo implementó MQTT para integrar a los proveedores y una nueva arquitectura de microservicios con Kafka para canalizar el tráfico de medidas.

04Proceso e intervención

Recibir medidas de electricidad y agua mediante MQTT → Canalizar el tráfico con Kafka y microservicios → Ajustar la ingesta al ritmo de envío de los proveedores.

05Aprendizaje

Se consiguió una aplicación operativa para grandes poblaciones. El aprendizaje fue adaptar la velocidad de ingesta de la plataforma a la velocidad de envío de los proveedores para sostener un buen ritmo de procesamiento.

Base del relato: Relato de primera mano de Raúl Plaza, participante y responsable del contenido. Resultados cualitativos, sin métricas auditadas.