Professional services
APIs and microservices, used where they help rather than by default
Well-designed APIs let your systems and partners connect without a project each time. Microservices solve a specific set of problems — and create others when adopted for fashion.
The situation
Every connection is a project
Without a deliberate interface, each new partner, app or system becomes bespoke work — and each one is another thing to maintain.
- Every new integration requiring custom development
- Partners asking for data you can only send as a file
- One large application where any change requires a full release
- Teams blocked waiting on another team's release cycle
- No documented way for anything to talk to your systems
- The same data exposed three different ways for three consumers
What it covers
What this work covers
API design
Interfaces designed around what consumers need, versioned so they can evolve without breaking the people using them.
Documentation
Documentation good enough that a third party can integrate without contacting you, which is the real test of an API.
Security
Authentication, authorisation, rate limiting and key management, because a public interface is an attack surface.
Service decomposition
Where it helps, splitting a large application along genuine boundaries rather than arbitrary ones.
Gateway and management
One controlled entry point, so routing, throttling and monitoring are not reimplemented per service.
Observability
Tracing and monitoring across services, without which a distributed system is very hard to debug.
How we work
How the work runs
Start from the consumer. An API designed around the internal data model rather than the caller's need produces something technically correct that nobody wants to use.
Understand the consumers
Who will call this, what they are trying to achieve, and what they will do with the response.
Design the contract
Agree the interface before implementing it, including versioning and what happens when it has to change.
Build and document
Implement with documentation and examples produced alongside, not written afterwards from memory.
Operate
Monitoring, rate limiting and a deprecation policy, so the API can be changed without stranding its consumers.
Outcomes
What you are left with
- A documented way for systems and partners to connect
- New integrations that are configuration rather than projects
- Interfaces that can change without breaking their consumers
- Services that can be released independently, where that is warranted
- One controlled, monitored entry point
- The ability to answer a partner's integration question with a link
Platforms and tooling
What we build with
APIs
- REST
- GraphQL
- OpenAPI
- gRPC
- Webhooks
Platform
- Azure API Management
- AWS API Gateway
- Kubernetes
- Docker
Messaging
- Azure Service Bus
- RabbitMQ
- Kafka
- Event-driven patterns
Named as platforms we work with, not as formal partnerships.
Common questions
Questions we are usually asked
Probably not, and that is worth saying plainly. Microservices solve problems of team scale and independent release. If one team releases one application, they mostly add distributed-systems complexity — network failure, data consistency, harder debugging — in exchange for benefits you are not yet in a position to use.
Sometimes, but a badly structured monolith usually becomes badly structured microservices with a network in between. Fixing the internal boundaries first is cheaper, and it tells you where the real seams are if you do decide to split later.
Versioning and a deprecation policy from the start. Once external consumers depend on an interface, changing it without a version strategy means either breaking them or freezing the design permanently.
Only if you intend to support it. A public API is a product with users, documentation and a support obligation. Many organisations need a well-designed private interface for their own systems and partners, which is a much smaller commitment.
Distributed calls are slower than in-process ones, and that cost is easy to underestimate. Caching, batching and sensible boundaries matter — an architecture that requires twelve service calls to render one screen will be slow whatever the individual services do.
Usually yes, and it is one of the most useful things you can do with a legacy system. It lets modern software integrate immediately while the question of replacing the old system is decided separately.
Talk to someone who has built this
Not a salesperson working from a form. Tell us what the problem looks like and someone who has delivered this kind of work will come back to you, usually within one working day.
Book a free consultationRelated
Where this usually connects
- Systems integrationMaking the systems you already own talk to each other.
- Enterprise service busA single integration layer instead of point-to-point connections.
- Legacy modernisationFor the system nobody wants to touch but everything depends on.
- Web application developmentBrowser-based applications for work that outgrew a spreadsheet.
- Cloud servicesMoving to cloud, or making an existing cloud estate behave.
- Agile and DevOpsShorter release cycles and a build pipeline you can rely on.