Overview
Order management issues can impact customer experience, revenue accuracy, and system performance. Common problems include:- N+1 query problems causing slow response times
- Discount calculation errors
- Order total miscalculations
- Stock management bugs
Incidents
INC-005: Orders endpoint response time increased to 8 seconds
INC-005: Orders endpoint response time increased to 8 seconds
Incident Details
- Severity: P2 - High
- Service: python-service
- Environment: Production
- Reported: 2026-02-28T08:00:00Z
- Status: Resolved
Problem
TheGET /api/orders endpoint response time degraded severely from ~200ms to over 8 seconds after adding order items to the response payload. Database CPU utilization spiked to 85% during peak hours. The endpoint was executing hundreds of SELECT queries per single API call.Symptoms:- Response time: 5-10 seconds for users with 10+ orders
- Database CPU: 85%+ during peak hours
- Excessive database queries logged
Root Cause
Classic N+1 query problem. The code was iterating through orders and lazily loading relateditems and product data for each order individually, resulting in:- 1 query to fetch all orders
- N queries to fetch items for each order
- N×M queries to fetch product details for each item
app/routes/orders.py:11-32Problematic Code
orders.py
Resolution
Use SQLAlchemy’s eager loading withjoinedload() to fetch all related data in a single query:orders.py
- Response time: Reduced from 8s to ~150ms (98% improvement)
- Query count: From 61 queries to 1 query
- Database CPU: Dropped from 85% to 15%
Prevention
- Query monitoring: Use Flask-SQLAlchemy’s
get_debug_queries()in development - Performance testing: Load test endpoints with realistic data volumes
- Database logging: Enable slow query logging to catch N+1 issues early
- Code review: Watch for loops that access relationship attributes
- ORM best practices: Use
joinedload(),selectinload(), orsubqueryload()for relationships
Detection Query
Add this middleware to detect N+1 queries in development:INC-006: Discount code applied twice during checkout
INC-006: Discount code applied twice during checkout
Incident Details
- Severity: P1 - Critical
- Service: python-service
- Environment: Production
- Reported: 2026-02-27T19:00:00Z
- Status: Resolved
Problem
Customers’ discount codes were being applied twice during checkout, resulting in incorrect order totals and revenue loss. A 80, but customers were charged only 100 → 64).Impact:- Revenue loss on discounted orders
- Customer confusion about pricing
- Accounting discrepancies
Root Cause
The discount was being applied twice in the order creation flow:- Once in
apply_discount()which returned the discounted subtotal - Again by subtracting
discount_amountfrom the already-discounted subtotal
subtotal * (1 - rate) - (subtotal * rate) instead of subtotal * (1 - rate).Location: app/routes/orders.py:81-91Problematic Code
orders.py
Resolution
Remove the duplicate discount subtraction sinceapply_discount() already returns the discounted subtotal:orders.py
Alternative Solution
For clearer semantics, track original subtotal separately:orders.py
Prevention
- Unit tests: Test discount calculations with known values
- Variable naming: Use clear names like
original_subtotalvsdiscounted_subtotal - Function contracts: Document what values functions return (pre/post discount)
- Integration tests: Verify end-to-end checkout totals
- Code review: Pay special attention to financial calculation logic
Test Cases
Common Patterns
Eager Loading Relationships
Discount Calculation Pattern
Order Total Calculation
Quick Reference
| Issue Type | Symptom | Solution |
|---|---|---|
| N+1 Query | Slow response, many DB queries | Use joinedload() or selectinload() |
| Double discount | Total too low by discount amount | Remove duplicate discount subtraction |
| Tax calculation error | Tax on wrong amount | Clarify pre/post discount tax calculation |
| Stock inconsistency | Negative stock values | Use database transactions and locks |