Software & Platforms
The full domain, and the other capabilities within it.
API & Integration
Integration designed for the day the network fails, not only for the day the demo works.
What this is
Integration is the work of making separate systems behave as one: an API gateway that presents a coherent surface, a message broker that decouples producers from consumers, and connectors that speak each system's own protocol. We design the contracts, build the flows, and instrument them so that failure is visible while it is still small.
The failure mode is always the same, and it is always discovered in production. An integration built on a plain HTTP call with no idempotency key, no retry policy and no dead-letter queue will lose messages the first time a network blips, or duplicate them the first time a timeout is retried. Both are silent. You learn about them from a reconciliation mismatch weeks later.
When you need it
If more than one of these is true, this is usually the right place to start.
- Two systems disagree about the same record and nobody can reconstruct which message was applied when.
- A nightly file transfer breaks, and the first indication is a business user asking why yesterday is missing.
- Every new external connection is a bespoke project because there is no gateway, no contract and no reusable pattern.
- An upstream change broke three consumers at once, because nobody knew who was calling that endpoint.
What the scope covers
- Contract-first API design specified in OpenAPI or AsyncAPI, including a versioning and deprecation policy consumers can plan against.
- Gateway configuration: authentication, authorisation, rate limiting, quotas and request validation applied at the edge.
- Event and messaging design on a broker such as Kafka or RabbitMQ, with delivery guarantees and ordering assumptions stated explicitly.
- Idempotency keys, retry with backoff, dead-letter handling and a replay procedure, designed before the first flow is built.
- Distributed tracing, error alerting and per-consumer usage analytics, so a broken integration announces itself.
What you receive
| Deliverable | What it contains |
|---|---|
| API specifications | Versioned OpenAPI or AsyncAPI contracts with worked examples and a deprecation policy, published where internal and external consumers can actually find them. |
| Gateway and broker config | Infrastructure as code for the gateway, broker and connectors, applied through your pipeline rather than clicked into a console. |
| Integration flows | The running integrations with idempotency keys, retry policy, dead-letter queues and a replay procedure someone on call can follow. |
| Observability pack | Tracing across service boundaries, per-consumer usage dashboards, and alerts tied to the failure modes each flow can actually have. |
Reference architecture
A reference, not a template. Your estate decides which parts apply and in what order they arrive.
How success is measured
Targets are agreed with you before the work starts, and reported against for its duration.
- Message success, retry and dead-letter counts per flow, with the age of the oldest unprocessed message always visible.
- End-to-end latency across the whole hop chain, traced rather than inferred from each service reporting its own timings.
- Contract violations and error rates per API consumer, so a misbehaving client is identified rather than blamed on the platform.
Questions we are asked
REST, GraphQL, gRPC or events — which should we use?
Each answers a different question. REST for broad, cacheable, external-facing surfaces. GraphQL where clients need to shape their own queries and you accept the caching and complexity cost. gRPC for chatty internal service-to-service calls. Events where the producer should not have to know who consumes. Most real estates use several, and the mistake is picking one for everything.
How do you version an API without breaking consumers?
Additive changes go into the current version; breaking changes get a new one, with both running while consumers migrate. That requires knowing who your consumers are, which is why per-consumer usage analytics matter more than they first appear to. A deprecation policy with dates published in advance is what makes the migration possible at all.
Do we need a message broker, or is HTTP enough?
HTTP is enough when the caller can usefully wait for the answer and can safely retry it. A broker earns its operational cost when the consumer may be down, when load spikes must be absorbed, or when several systems need the same event. It also adds a system you have to run, which is worth saying plainly before it appears on the diagram.
Can you guarantee exactly-once delivery?
In a distributed system there is no exactly-once delivery. There is at-least-once delivery plus idempotent processing, which together produce an exactly-once effect. That is why every consumer we build has an idempotency key and a de-duplication strategy. Anyone promising exactly-once at the transport layer is describing something else.
Can you integrate legacy systems that have no API?
Usually. The options are database views with change tracking, file exchange with a checksum and manifest, terminal or screen automation as a last resort, and a strangler layer that fronts the old system behind a stable contract. Each has different failure characteristics, and we will name them, because a fragile connector needs monitoring built in from the first day.
How do you secure the integration surface?
Authentication and authorisation at the gateway with OAuth 2.0 or mutual TLS, per-consumer credentials and rate limits, request validation against the published schema, and secrets held in a managed store rather than in configuration files. Payload-level controls such as field encryption, signing and data minimisation are decided against what actually crosses the boundary, not applied uniformly.
Continue reading
SaaS Products
Multi-tenant SaaS engineering where tenancy, metering, entitlements and progressive release are design decisions taken before the first enterprise customer.
Web Applications
Web applications built to an accessibility and performance budget from the first commit — architecture, API layer, CI/CD and observability you own.
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.