Behind every challenge, a decision.

01Context and constraints

Participation in euro-payment development for payments originating in the UK in the context of Brexit, a bank’s Bizum implementation and integration with fintechs in the same group.

The flow needed to absorb a high volume of information while working with external APIs that required synchronous communication.

Scope: Development and integration as part of a team; creation of the entire service is not attributed to one person.

02Friction and risk

An asynchronous architecture alone could not handle every exchange: some steps depended on third-party responses.

03Decision and trade-offs

Implemented decisions as described by the content owner; the comparison explains their roles and trade-offs.

The team chose an asynchronous architecture with Kafka and Spring Boot microservices. Synchronous communication was retained where third-party APIs required it.

04Process and intervention

Process payment information through Kafka → Implement business logic in Spring Boot microservices → Integrate external APIs and refine each step of the flow.

05Learning

The intended objective was achieved through successive adjustments. The lesson was to combine asynchronous processing with actual synchronous dependencies, rather than impose a single pattern on every integration.

Narrative basis: First-hand account by Raúl Plaza, a participant and the content owner. Qualitative outcomes, without audited metrics.

01Context and constraints

Design of a medical information hub bringing together appointments, diagnoses, care encounters and information about patients and healthcare professionals.

The system needed to absorb millions of data items each day and provide access to external applications. This volume describes the project requirement, not an audited performance measurement.

Scope: Technology leadership and architecture design, including an API to access stored information.

02Friction and risk

Requirements kept evolving: the platform needed to accommodate changes without being constrained by its initial design.

03Decision and trade-offs

Implemented decisions as described by the content owner; the comparison explains their roles and trade-offs.

Microservices with asynchronous communication were chosen for ingestion, alongside an API for third-party applications that needed to query the information.

04Process and intervention

Bring in clinical and care information → Process it through asynchronously communicating microservices → Provide API access and evolve the modules.

05Learning

The platform is operational and its architecture has evolved with project needs. Modularity has enabled changes from the initial design. The lesson is to treat architecture as a structure that evolves with use.

Narrative basis: First-hand account by Raúl Plaza, a participant and the content owner. Qualitative outcomes, without audited metrics.

01Context and constraints

Refactoring parts of a metering product and designing a microservice architecture to channel data from external providers.

Providers sent readings at their own pace; the platform needed to adjust its ingestion capacity to that traffic.

Scope: MQTT integration with external IoT providers and routing electricity and water readings through microservices and Kafka.

02Friction and risk

Receiving large volumes of readings required coordinating incoming integrations with internal processing.

03Decision and trade-offs

Implemented decisions as described by the content owner; the comparison explains their roles and trade-offs.

The team implemented MQTT to integrate providers and a new microservice architecture with Kafka to channel meter-reading traffic.

04Process and intervention

Receive electricity and water readings through MQTT → Channel traffic through Kafka and microservices → Adjust ingestion to the providers’ sending rate.

05Learning

An operational application serving large population centres was achieved. The lesson was to adapt the platform’s ingestion speed to the providers’ sending rate to sustain a good processing pace.

Narrative basis: First-hand account by Raúl Plaza, a participant and the content owner. Qualitative outcomes, without audited metrics.