Defect Management and Bug Lifecycle Questions

Title: Intermittent HTTP 500 from /api/v1/login under high concurrent load

Steps to reproduce:

• Run a load test targeting POST /api/v1/login with realistic payloads (valid username/password) at ~200–500 RPS for 5–10 minutes.
• Use a pool of ~1,000 unique user credentials to avoid cache hits and simulate real traffic.
• Observe responses and server logs; reproduce across staging and production if possible.
• Note that lower load (<100 RPS) does not trigger the failure consistently.

Expected behaviour:

• Login requests return HTTP 200 with a session token (or HTTP 401 for invalid creds); no 5xx errors under expected peak load.

Actual behaviour:

• A subset (~1–5%) of login requests intermittently returns HTTP 500 with stack traces referencing auth-service DB connection or thread-pool exhaustion. Failures correlate with spikes in concurrent requests.

Scope / impact:

• Affects user login during traffic spikes; causes failed sign-ins for a small but significant percentage of users, increasing support tickets and potentially blocking sessions for new users. Observed in production and reproducible in staging under load.

Suggested temporary workaround:

• Reduce incoming login concurrency via rate-limiting or a brief traffic throttle behind the load balancer, and enable retries with exponential backoff on the client for idempotent login attempts while we investigate root cause.