Skip to content
Akshay Kakoriya

Azure integration architect

Integration that survives the third party having a bad day.

The systems I work on are the ones that talk to suppliers, partners and services a company does not control — and most of the interesting decisions are about what happens when one of them stops answering. That is where the design work goes: API-first, event-driven, on Azure. Lately the same decisions have followed me into AI systems on Azure AI Foundry.

Now · Agentic systems on Azure AI Foundry — boundaries, evaluation harnesses and the observability to tell which decision fired — and writing up the reliability patterns the integration work has always run on.

What I work on

Integration architecture on Azure

API Management, Service Bus, Event Grid, Logic Apps and Functions, arranged so that adding the fiftieth interface is boring. The work that decides whether it will be happens before anyone builds: the contract, the boundary, and who gets paged when it breaks.

Reliability, designed in

Retry, dead-letter, idempotency and circuit breaking are not a checklist. They are a set of decisions about what a system should do at two in the morning when a dependency goes quiet — and the instrumentation that tells you which decision fired.

AI on the same foundations

Agentic systems on Azure AI Foundry, held to the standard integration already sets: boundaries you can point to, evaluation you can run, observability that survives contact with production. The hard parts turn out to be ones integration has met before.

How I think

I start from the failure, not the happy path.

An integration is defined by what it does when the other side is slow, wrong or gone, so that is where the design work goes first. Every choice that matters gets written down — what was considered, what was chosen, what it cost — because the decision is the part a team inherits. The happy path mostly takes care of itself.

Scroll the diagram sideways

A caller retries a failing service three times, with the interval growing between each attempt, up to a fixed attempt limit. attempt 1 · immediate attempt 2 · +2s attempt 3 · +4s, then stop Caller idempotent op Service transient fault add jitter, or every caller retries on the same schedule
Bounded retry with backoff: the first thing I look for in any integration, and the thing most often wrong. Without jitter, every caller retries on the same schedule and the recovering service is hit by a wall.

Latest writing

All writing →

Say hello

I write here about integration, reliability, and the AI systems now being built on top of them. If something I have written is wrong, or you are working on the same problems, I would like to hear about it.

Email me LinkedIn (opens in a new tab)