Skip to main content

Integration and APIs

API and integration foundation across eleven systems

Versioned contracts, idempotency and incident recovery

Opérateur de services publics (exemple) - 2023-10 - 2024-06

Demonstration sample: this case study illustrates the Codexway method and does not refer to a real client.

Context

Eleven business applications exchanged data through files dropped on shared servers and through direct database calls. Three external partners also consumed those interfaces, with no formal contract and no dedicated test environment.

Problem

Integration incidents were diagnosed by cross-referencing heterogeneous logs, duplicate processing was detected by the accounting team, and a file structure change silently broke a consumer identified several days later.

Objectives

  • Formalise and version exchange contracts with partners
  • Guarantee no duplicates when a message is resent
  • Make every failed message visible and replayable

Role

Lead designer and main developer on the integration foundation, paired with an internal developer on the business connectors.

Solution

The first step was an exhaustive flow inventory: one hundred and forty-two exchanges identified, of which twenty-three genuinely critical and nine documented nowhere but in code. Each flow was qualified by volume, frequency, business criticality and tolerance to partner downtime. Synchronous exchanges were rebuilt as REST APIs with versioned OpenAPI contracts; notifications and long-running processing moved to Kafka events. Every message carries an idempotency key and a correlation identifier, which makes it possible to replay a flow without creating duplicates and to trace its entire path. Failed messages are isolated in a dedicated queue, visible from an operations dashboard. First-level support can replay a message after fixing the data, without developer involvement.

Architecture

A central integration foundation exposes internal and partner APIs, with OAuth 2.1 authentication and scope-based authorisation. Connectors to legacy systems translate old formats into the target contracts so those systems remain untouched. Kafka distributes business events, with versioned schemas validated at publish time. Redis tracks idempotency keys in the short term. All interactions are traced with OpenTelemetry, with an identifier propagated from the initial call through to end-to-end processing.

Results (samples)

  • Versioned and published API contracts for partners
  • Error queue inspectable and replayable by first-level support
  • Removal of file-based exchanges on shared servers
  • Integration documentation available to external partners

Indicators (samples)

  • Integration flows catalogued

    142

    Figure from a simulated inventory — demonstration sample

  • Critical flows documented before the work

    9 of 23

    Simulated starting situation — demonstration sample

  • Exchange incident diagnosis time

    a few hours to 20 minutes

    Indicative order of magnitude — demonstration sample

Technologies

  • Java
  • Spring Boot
  • PostgreSQL
  • Redis
  • Apache Kafka
  • Docker
  • OpenTelemetry
  • OAuth 2.1 et OpenID Connect

Testimonial (sample)

« The most tangible change for our teams is being able to see a failed message and replay it ourselves. Before, that always required a developer. »

- Public services operator (demonstration sample)

Related services

  • Java and Spring Boot back-end development

    I design and build robust business services with Java and Spring Boot, tested and observable from day one. The delivered code is readable, documented and easy for your team to take over.

  • Application security and API protection

    I secure your applications where it actually matters: identities, authorisations, secrets and input validation. The measures are verifiable and integrated into the delivery pipeline.

  • APIs and system integration

    I design the exchanges between your applications, partners and legacy systems, with stable contracts and full traceability. Integrations stop being a permanent weak point.

  • Observability and application performance

    I make your applications diagnosable: correlated traces, useful metrics and alerts that signal a real problem. You move from interpreting symptoms to identifying the cause.