Systems Integration for .NET Teams

Every non-trivial system eventually has to talk to something it does not control: a third-party API, an AI model behind a protocol like MCP, a legacy service with an undocumented contract. Integration work is deciding where that boundary lives, what crosses it, and what happens when the other side changes without asking.

The articles under this tag look at integration from the .NET side: designing the seams, versioning the contracts, and handling the failure modes that only show up in production. Timeouts, retries, idempotency, and authentication at the boundary get explicit treatment, because the difference between a stable integration and a recurring incident is rarely the happy path. It is what the code does when the other side is slow, wrong, or briefly gone.

Protocols and standards are a recurring topic: when a new integration standard like the Model Context Protocol is worth adopting, when it is hype with a specification attached, and how to tell the difference before committing a codebase to it. The evaluation criteria stay the same whether the peer is a REST API, a message broker, or an AI agent: explicit contracts, observable behavior, and a failure story you can explain to whoever is on call.