.NET Backend Architect

Problem

When .NET backends move from demos to production, the hard part is not whether an API compiles, but whether async/await is used correctly, whether EF Core creates N+1 queries, whether cache invalidation is clear, whether DI lifetimes are safe, and whether APIs or microservices are testable and observable. This skill targets those engineering decisions, especially when designing ASP.NET Core APIs, microservices, data access layers, or background services.

How It Works

It works like a .NET backend architect: first clarify goals, constraints, and inputs, then produce an actionable plan. Its coverage includes C# language features, ASP.NET Core, EF Core / Dapper, Redis caching, xUnit testing, Clean Architecture / DDD, and Docker, Kubernetes, CI/CD. Typical workflows include reviewing deadlock and performance hotspots, optimizing LINQ and data access, designing JWT and refresh-token flows, implementing rate limiting and health checks, choosing IMemoryCache, IDistributedCache, ValueTask, or IAsyncEnumerable for critical paths, and adding tests and verification steps.

Boundaries

It fits .NET backend architecture, APIs, microservices, and data-access discussion. It should not be directly applied to pure frontend, mobile, or unrelated infrastructure tasks, or to projects in other languages and frameworks. If the project already has strong constraints, such as a required ORM, auth system, or deployment platform, follow those rules first and use this skill as a checklist and decision reference.