Essential session storage is required to sign in. Optional analytics remain off unless you allow them.
Take an ASP.NET Core service to production. Deliver: (1) a well-designed, versioned HTTP API documented with OpenAPI/Swagger, with consistent ProblemDetails errors and CORS; (2) performance hardening — fully async, a distributed cache (IDistributedCache/Redis) for hot reads, and rate limiting; (3) at least one ADVANCED capability where it fits — SignalR real-time, a gRPC service, or a BackgroundService for async work; (4) CONTAINERIZED deployment (multi-stage Dockerfile on the official .NET images) running Kestrel behind a reverse proxy, with per-environment config and secrets handled safely; and (5) OBSERVABILITY — health checks (liveness/readiness), OpenTelemetry traces/metrics/logs, and graceful shutdown. Document the architecture and how you'd scale it.
Versioned REST API with OpenAPI/Swagger, ProblemDetails, CORS; consistent and discoverable.
Fully async; distributed cache + rate limiting; one of SignalR/gRPC/BackgroundService implemented correctly.
Multi-stage Docker on .NET images; Kestrel behind a reverse proxy; per-env config + safe secrets.
Health checks + OpenTelemetry + graceful shutdown; architecture and scaling documented.
Use this README structure to make the work reviewable.
DevPath fetches a read-only, size-capped snapshot. Submitted code is never executed.
# A deployed, observable .NET service ## Goal Take an ASP.NET Core service to production. Deliver: (1) a well-designed, versioned HTTP API documented with OpenAPI/Swagger, with consistent ProblemDetails errors and CORS; (2) performance hardening — fully async, a distributed cache (IDistributedCache/Redis) for hot reads, and rate limiting; (3) at least one ADVANCED capability where it fits — SignalR real-time, a gRPC service, or a BackgroundService for async work; (4) CONTAINERIZED deployment (multi-stage Dockerfile on the official .NET images) running Kestrel behind a reverse proxy, with per-environment config and secrets handled safely; and (5) OBSERVABILITY — health checks (liveness/readiness), OpenTelemetry traces/metrics/logs, and graceful shutdown. Document the architecture and how you'd scale it. ## Acceptance criteria - [ ] API design & docs: Versioned REST API with OpenAPI/Swagger, ProblemDetails, CORS; consistent and discoverable. - [ ] Performance & advanced: Fully async; distributed cache + rate limiting; one of SignalR/gRPC/BackgroundService implemented correctly. - [ ] Deployment: Multi-stage Docker on .NET images; Kestrel behind a reverse proxy; per-env config + safe secrets. - [ ] Observability: Health checks + OpenTelemetry + graceful shutdown; architecture and scaling documented. ## Verification - [ ] Document installation and run commands. - [ ] Record automated checks and their exact commands. - [ ] Add representative output, screenshots, or a short demo where useful. - [ ] Confirm failure paths and known constraints. ## Decision log ### Decision title - Context: - Choice: - Alternatives considered: - Tradeoffs: ## Evidence - Link each rubric criterion to the file, test, or artifact that demonstrates it. ## Known limitations - List what is intentionally out of scope and what should be improved next.