Scenario: The AI-Generated Rate Limiter
A recent graduate in their first technical interview is asked to implement a rate-limiting middleware using Redis to protect a public API. To speed things up, the candidate turns to an AI coding assistant. The LLM immediately outputs the following Python snippet:
def check_rate_limit(user_id):
requests = redis.get(user_id)
if requests and int(requests) > 100:
return False # Rate limit exceeded
redis.incr(user_id)
if not requests:
# If this was the first request, set the expiration to 1 hour
redis.expire(user_id, 3600)
return True
The candidate looks at the code, notes that it is clean and readable, and submits it as their final answer.
Q:You ask the candidate to stress-test this code. If 50 concurrent requests arrive from the exact same user at the exact same millisecond, what specific concurrency flaw will allow all 50 requests to bypass the limit? Reveal â–¾
The code suffers from a classic Read-Modify-Write Race Condition (Time-of-Check to Time-of-Use).
Because the operations are not atomic, all 50 threads will simultaneously execute redis.get(user_id) before any thread has a chance to execute redis.incr(user_id). All 50 threads will read requests = None. All 50 threads bypass the > 100 check, increment the counter, and return True. The rate limit is entirely useless under concurrent load.
Q:You point out the race condition. The candidate argues that even if a few requests slip through, the expire block will eventually reset the counter, so the system recovers. What edge-case network failure turns this assumption into a permanent denial-of-service for that user?
Reveal â–¾
The vulnerability lies between redis.incr(user_id) and redis.expire(user_id, 3600).
If the application server crashes, or a network partition severs the connection to Redis immediately after the incr command but before the expire command is sent, the Redis key is created with no TTL (Time-To-Live). The key will increment indefinitely but will never expire. Once the user hits 100 requests, they are permanently locked out of the system until a database administrator manually deletes the key.
Q:This evaluates the candidate’s ‘AI Fluency’. If the candidate recognizes these flaws, how should they properly prompt the AI, or rewrite the code, to guarantee absolute atomicity in Redis? Reveal â–¾
A fluent engineer knows that network bounds require atomic data-store operations. They should rewrite the logic using a Redis Lua Script or utilize modern atomic compound commands.
By sending a Lua script to Redis, the entire block of logic (get, check, increment, expire) is executed atomically directly within the single-threaded Redis engine. No other Redis commands can interleave. Alternatively, they can use pipeline constructs or the SET command with EX (Expire) and NX (Not Exists) flags to establish the baseline safely without multiple network round-trips.
Variations & Real-World Impact
- Prompt Injection in Code Generation: Modern interviewers are testing whether candidates blindly trust AI logic. An LLM trained on millions of GitHub repos will frequently replicate the most common architectural mistakes (like missing database transactions or insecure direct object references) because they are statistically common, not because they are correct.
- Security Linters: In a real CI/CD pipeline, AI-generated code must be subjected to static application security testing (SAST). However, SAST tools often miss logical race conditions like this one, requiring human architectural intuition to catch.
Discussion & Comments