Software architecture
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.
What it covers
Integrations become expensive when they rely on implicit exchanges: formats agreed by email, undefined retry rules, no visibility on failed messages. So I start by formalising contracts and each party's responsibilities.
Depending on the case, exchange happens through a synchronous API or an event stream. The choice follows explicit criteria: tolerance to partner downtime, volume, replay needs and data consistency constraints. A single platform can combine both approaches.
Traceability and incident recovery
Every message is identifiable, timestamped and retained long enough to allow replay. Errors are isolated in a dedicated queue, visible to operations, and processing is idempotent so a resend never creates duplicates.
- Versioned and published API contracts.
- Compatible event schemas validated at publish time.
- Idempotent processing and correlation keys.
- A failed message queue operations can inspect.
- An exchange journal for audit purposes.
Problems addressed
Exchange formats are documented nowhere. Failed messages vanish with no usable trace. Partner downtime blocks an entire business process. Duplicate processing is discovered by the finance team. Every interface change breaks an unidentified consumer.
Expected benefits
Documented exchanges understood by all parties. Recovery after incidents without data loss. Integrations you can test without depending on partner availability. Operations that can see and replay failed messages. Controlled contract evolution with no abrupt breakage. An audit trail usable in case of dispute.
Method and steps
- 1
Exchange mapping
Cataloguing application and partner flows with volumes, frequency, business criticality and observed failure points.
- 2
Contract definition
Writing API specifications and event schemas, versioning rules, error codes and latency commitments.
- 3
Implementation
Building connectors and adapters with idempotency, correlated logging and explicit handling of permanent errors.
- 4
Validation and go-live
Load testing, downtime simulations, replaying failed messages, then operations documentation and handover to the teams.
Deliverables
Flow map with criticality and owners.
Versioned API specifications and event schemas.
Implemented and tested connectors.
Replay and failed-message handling procedures.
Exchange monitoring dashboard.
Operations documentation and handover session.
Technologies used
- Java
- Spring Boot
- PostgreSQL
- Redis
- Apache Kafka
- Docker
- OpenTelemetry
- OAuth 2.1 et OpenID Connect
Frequently asked questions
Should we favour APIs or events?
Synchronous APIs suit queries and operations where the result is expected immediately. Events suit notifications, long-running processing and situations where the partner may be temporarily unavailable. Most platforms combine both.
How do you handle systems that cannot change?
I add an adaptation layer that translates legacy formats into the target contracts. The legacy system stays untouched, but its interface becomes stable and documented for consumers.
What happens if a partner is unavailable for hours?
Messages are retained and replayed automatically on recovery, in order and without duplicates thanks to idempotency keys. Retention duration and alerting rules are agreed with you based on business criticality.
Related case studies
API and integration foundation across eleven systems
Versioned contracts, idempotency and incident recovery
Demonstration sample - not a real client reference.
Talk about my integrations
Describe the flows involved and the incidents you observe. We will define a small pilot scope with measurable success criteria.