– EXPERIENCE AND TRUST –

Projects that make an impact

Every project brings a different challenge. From real-time integration architectures and data platforms to critical 24×7 operations, we help leading organisations accelerate innovation, improve operational efficiency and build future-ready solutions. Explore some of the case studies that have shaped our journey.

Success stories

Insurance

Real-time data for one of the world's largest insurance groups

We modernised the financial, accounting and analytics architecture of the Brazilian operation, with real-time integrations via Apache Kafka and Confluent, and a highly secure platform for international data processing. Find out more

Read More

Success stories

Healthcare

A Centre of Excellence for Latin America's largest healthcare network

We consolidated operations, support and projects into a single integration structure. Hospital events are now processed in around 20 seconds, with the claims-denial process fully automated. Find out more

Read More

Success stories

Retail

Fluid Stock and unified operations for one of Brazil's largest retailers

We supported the digital transformation with a modern architecture built on React, React Native, Java and RabbitMQ, creating the Fluid Stock concept and unified management of inventory, orders and dispatch. Find out more

Read More

We’re ready to help you move forward, efficiently.

– success story – insurance –

Modernising financial integrations

From legacy batch processing to a resilient, event-driven architecture.

A large financial services company set out to fundamentally transform its integration architecture in Brazil.

The challenge

For years, critical accounting, payment, financial posting and regulatory data processes had relied primarily on legacy integrations based on file transfers and batch processing.

The challenge went far beyond simply replacing interfaces.

The Brazilian financial ecosystem had to migrate to the global corporate standard, centralising integrations on a financial platform used by the organisation in the United States while maintaining compatibility with local systems that would remain in operation.

This involved modernising dozens of workflows across insurance, payments, HR, accounting and regulatory systems, while keeping legacy systems running throughout the transition.

A hybrid architecture: batch and real time

Not every integration had to become real-time.

One of the main architectural challenges was determining which processes were better suited to high-volume batch processing and which should evolve towards an asynchronous, event-driven model.

The new architecture supported both models.

Strategies tailored to the nature of each integration

For transactional integrations and events that had to move quickly between systems, asynchronous services were developed in Java and Spring Boot, using APIs and messaging mechanisms.

For high-volume financial loads, batch processing was retained and modernised with additional controls for security, traceability and recovery.

Different communication strategies were adopted according to the nature of each integration:

  • Apache Kafka / Confluent for messaging and events;
  • Java and Spring Boot for integration services;
  • REST APIs, with contracts defined in OpenAPI/YAML;
  • Apigee for API exposure and management;
  • batch and multipart processing for large volumes;
  • asynchronous callbacks for processing confirmation;
  • Oracle EBS as the corporate financial platform;
  • integrations with platforms such as XRT, Pagnet and core insurance systems;
  • monitoring of integration events and status.

The goal wasn’t simply to move information between systems, but to build an integration layer capable of bridging the differences between local systems and the global financial platform.

High volume without compromising security or performance

Some financial integrations involved very large files.

In these scenarios, simply moving the original file across the infrastructure wasn’t sufficient.

A dedicated compression and decompression mechanism was implemented for batch processing, reducing the volume of data transmitted and improving processing efficiency.

The pipeline also had to handle financial and personal data subject to strict security requirements.

The solution incorporated mechanisms to encrypt sensitive columns and protect individual fields; identify and remove confidential information from events before publishing them to Kafka, preventing unnecessary or sensitive data from circulating on the messaging platform; and retain only the information required to process each integration.

This approach combined high throughput with privacy by design, preventing the event platform from becoming an indiscriminate repository of confidential information.

Modernisation without rewriting every legacy system

Another key challenge was ensuring that financial modernisation didn’t require every existing system to be changed at once.

Adapters were built to make this possible.

Legacy systems could continue producing certain files in their original format, while the new integration layer converted the information for the new services.

The same concept was applied to the return flow.

The modern platform processed the transaction, while the adapter transformed the response back into a format the legacy system could understand.

This strategy significantly reduced coupling during the transformation and enabled a gradual migration.

Resilience for critical financial processes

In a financial architecture, losing a message or partially processing a batch can have far greater consequences than a standard technical outage.

The solution was designed with a strong focus on resilience, traceability and consistency.

The workflows included:

  • Batch identification
  • Processing callbacks
  • Event logging
  • Failure handling
  • Monitoring of each integration through a dedicated observability layer

In accounting processes, certain batches followed an all-or-nothing integrity rule: a set of records had to be accepted in full or rejected as a single batch, preventing partial postings.

The result was an architecture capable of handling real-time integrations and large batch loads simultaneously, while preserving the controls required by financial systems.

From Brazil to a global financial platform

The transformation added another layer of complexity: it wasn’t only about modernising the technology.

Brazil’s accounting and financial integrations had to be adapted to the corporate financial model used by the parent company in the United States.

Systems, layouts, fields, business rules, accounting events, payments and returns in Brazil were mapped to operate with the new corporate instance of Oracle EBS.

The domains involved included:

  • Bank payments and returns
  • General Ledger (GL)
  • Accounting postings
  • Policy-issuance systems
  • Commissions and compensation
  • Deductibles
  • Employee data
  • Regulatory information
  • Financial transactions

More than an interface migration, the project created a modern interoperability layer between the Brazilian financial ecosystem and a global financial platform.

Key technologies
  • Apache Kafka
  • Confluent Platform
  • Databricks
  • Apache Spark
  • Delta Lake
  • Delta Live Tables
  • CDC
  • Debezium
  • FHIR
Integration engineering applied to critical systems

Integration-modernisation projects don’t have to choose between batch and real time. The right architecture uses each model where it makes the most sense.

In this project, modern services, events, APIs and Kafka coexisted with high-volume batch processing, legacy systems and corporate financial platforms.

The result was a more decoupled, resilient and secure architecture, ready to evolve without requiring the entire existing ecosystem to be replaced at once.

– success story – healthcare

Near-real-time analytics for hospital operations

A large healthcare operation set out to turn data generated in hospitals into actionable information within seconds.

Through new data modelling, a streaming architecture and processing optimisations, latency fell from around 20 minutes to approximately 20 seconds, in a model that now supports more than 100 hospitals.

The challenge

The data came from different hospital systems, including TASY, WPD and MV, each with its own structure and model.

The challenge wasn’t simply to speed up processing. It required a fundamental rethink of how the data was modelled, handled and made available.

The differentiator: modelling before tuning

The performance gains began with the data architecture. Before optimising the infrastructure, the information model itself was reviewed, with clear definitions for facts, dimensions, partitioning, relationships, lookup tables and incremental-processing strategies.

This redesign eliminated unnecessary steps, reduced data movement and enabled Spark, Delta and Delta Live Tables to run far more efficiently.

The result didn’t come from technical tuning alone, but from combining data engineering, analytical modelling and well-designed pipelines.

A high-performance architecture

The CDC used to capture data from transactional systems evolved into a custom Debezium-based implementation tailored to the hospital environment, providing greater control over event capture, transformation and publishing.

  • Apache Kafka
  • KSQLdb
  • Databricks
  • Apache Spark
  • Delta Lake
  • Delta Live Tables
  • CDC
  • Debezium
  • FHIR

Java with Quarkus and Node.js were used to build the services responsible for integrations and business rules.

RabbitMQ supported different asynchronous processing flows, while the Kafka ecosystem, enabled through Azure Event Hubs, allowed events to be distributed across the platform’s different components.

React and React Native were used in the web applications and applications supporting hospital operations.

The result was a distributed architecture capable of processing a high volume of hospital events and keeping different systems up to date without creating synchronous dependencies between every element in the chain.

From around 20 minutes to 20 seconds

By combining new data modelling, a streaming architecture and processing optimisations, latency — previously around 20 minutes — was reduced to approximately 20 seconds.

This made it possible to turn hospital data into usable business events almost as soon as care was delivered.

Use cases included:

  • Digital journeys
  • Communication triggers
  • Patient engagement during care
Analytics built to scale

Initially built for a controlled set of hospitals, the model has since evolved to support more than 100 hospitals.

More than implementing a data platform, the project demonstrated a core Best2Bee capability:

pinpointing the real performance bottleneck — whether in the architecture, data model, processing or infrastructure — and redesigning the solution so analytics can run at scale, in near real time.

– success story – Retail

Fluid Stock — omnichannel integration for a major retail operation

One of Brazil’s largest retail operations set out to address a challenge at the heart of its omnichannel strategy: ensuring that stock across physical stores, digital channels and the corporate ERP consistently and reliably reflected actual product availability with low latency.

With around 1,800 physical stores, any delay in propagating stock movements could create significant discrepancies between channels.

A product sold in-store could remain listed as available online for some time. Likewise, new stock received by stores wasn’t always immediately visible to other channels.

The challenge wasn’t simply to integrate systems.
It required an architecture capable of turning thousands of physical stores into an active part of the digital operation.

From store-level stock to network-wide stock

The Fluid Stock initiative aimed to bring physical and digital stock closer together, allowing store-level movements to propagate quickly across the ecosystem.

SAP, used as the corporate ERP, played a central role, while the applications and services supporting store operations had to keep stock information synchronised with digital channels.

The architecture shifted to stock-movement events, significantly reducing the time required for changes across roughly 1,800 stores to be reflected in other systems.

This narrowed the gap between stock physically available in stores and the stock shown to customers online.

Safety stock to protect in-store operations

Making store stock available to e-commerce didn’t mean exposing the entire quantity on hand.

The solution incorporated a minimum safety-stock threshold.

Part of the stock remained reserved for the store’s own local needs, while only the quantity genuinely available could be offered through digital channels.

This approach allowed stores to act as stock points within the omnichannel operation without compromising the experience of customers shopping in person.

O2O: connecting online purchases to the physical store

With a more up-to-date view of product availability, stores began to play an even greater role in the digital customer journey.

The architecture supported different O2O (Online to Offline) models, including:

  • online purchases collected in-store;
  • online purchases prepared and dispatched directly from the store.

 

In this model, a physical store is no longer just a point of sale — it also becomes part of the digital operation’s logistics network.
For this to work, stock, orders, preparation and availability all had to operate in a coordinated way.

From distribution centre to in-store availability

The project also covered the store-replenishment process.

When products were dispatched from Distribution Centres, the operational applications made it possible to track goods received at stores.

Confirming receipt updated the store’s stock and propagated the information across the ecosystem, including the corporate ERP and the services responsible for product availability.

The flow connected different stages of the chain:

Distribution Centre → in-store receipt → goods confirmation → stock update →
SAP → digital channels

In this way, the architecture tracked each product from its arrival at the store through to its availability for sale across different channels.

Event-driven architecture for a large-scale operation

To reduce coupling between systems and allow stock movements to be processed asynchronously, the architecture relied heavily on events and messaging.
Among the key technologies used were:

Java • Quarkus • Node.js • React • React Native • RabbitMQ • Azure Event Hubs / Kafka • SAP •
arquitetura orientada a eventos • microsserviços

Java with Quarkus and Node.js were used to build the services responsible for integrations and business rules.

RabbitMQ supported different asynchronous processing flows, while the Kafka ecosystem, enabled through Azure Event Hubs, allowed events to be distributed across the platform’s different components.

React and React Native were used in the web applications and applications supporting store operations.

The result was a distributed architecture capable of processing movements across around 1,800 stores and keeping different systems up to date without creating synchronous dependencies between every element in the chain.

Beyond stock: digitalising store operations

The evolution of Fluid Stock formed part of a broader transformation of store operations.

Beyond stock synchronisation and availability, solutions were developed for a range of retail processes, including:

  • receiving goods from the Distribution Centres;
  • in-store collection of orders placed on online channels;
  • dispatch of digital orders using the store itself as the point of origin;
  • product-exchange processes;
  • applications supporting day-to-day store operations.

 

These solutions shared the same architectural principle: connecting corporate systems, digital channels and physical operations through decoupled services and event-driven communication.

The physical store as part of the digital platform

The initiative’s main outcome went beyond the significant reduction in stock-synchronisation time.

The transformation made it possible to use stock distributed across roughly 1,800 stores as a genuine part of the organisation’s digital strategy.

By bringing SAP, physical stores, operational applications and e-commerce closer together, the architecture laid the foundations for a truly omnichannel operation, allowing customers to start their journey in one channel and complete it in another.

More than integrating stock levels, the project turned the store network into an extension of the digital commerce platform.

Powered by