The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
A client asked me why their API was randomly letting through too many requests.
Their rate limiter looked fine on paper.
Redis. Clean code. Correct limit.
The bug? They were doing this in Node.js:
const count = await redis.get(key);
if (count < limit) {
await redis.incr(key);
// allow request
}
Looks harmless. It's not.
Under load, 10 requests can all hit the GET simultaneously.
All read count = 4. All pass the check. All increment.
Now you're at 14 instead of 5.
This is a classic TOCTOU bug.
Time Of Check vs Time Of Use.
The fix is simple but non-obvious:
Wrap the GET + INCR inside a Lua script and run it via EVAL.
Redis executes Lua atomically.
No other command runs between your check and your write.
The race condition disappears completely.
The bugs that hurt most in production are never in your business logic.
They're in the invisible gaps between your commands
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Trending
retrofuturism
Share your favorite designs from the past exploring the distant future. Or your own take on the aesthetic 🚀
halftone
Dots. Texture. Grain. Let's see your designs using the halftone technique.
Midjourney
Creatives are showing off what they're making with Midjourney.
colorgrade
Video editors sound off: How do you enhance the mood of your video in color grading?
Related posts
Manufacturing facility managers were flying blind, relying on delayed reports and disconnected spreadsheets to monitor multi-line production status. A modern industrial operation needed a central nervous system. I designed and developed FABRIX AI — a high-performance, real-time command center that aggregates data across active production lines and delivers instant visibility into yield, OEE (Overall Equipment Effectiveness), and maintenance alerts.
The Challenge
Industrial environments generate massive amounts of data, but it's often siloed or presented in outdated, hard-to-read interfaces. The core challenge was twofold:
Data Aggregation: We needed to ingest live statuses, targets, and outputs from multiple concurrent production lines without latency.
Cognitive Load: Operators on the factory floor needed a UI that instantly communicated critical alerts (like yield drops or material shortages) without requiring them to dig through menus. The interface had to be deeply legible in low-light industrial environments while looking like a premium, modern SaaS product.
he FABRIX AI dashboard transformed raw factory data into an actionable, real-time narrative.
Facility managers now have a single pane of glass showing global OEE, total output, and granular line-by-line efficiency.
The high-contrast alert system dramatically reduces response times to yield drops and maintenance bottlenecks.
The fully responsive, single-page application structure allows the dashboard to be displayed on large factory floor monitors or accessed remotely by shift supervisors without losing visual hierarchy.
Your AI agent just did 9 things: pulled 412 orders, matched them to Stripe, caught a duplicate £248 charge, drafted a ledger entry, opened a ticket. Whole run cost $0.011.
Now the real design question — what does the user actually SEE?
A — The transcript. A paragraph of text and a collapsed "Used 3 tools".
B — The run canvas. Nine colour-coded rows: what ran, what it cost, what got flagged, and one step that stops and waits for you before money moves.
Same agent. Same run. Two completely different products.
Vote A or B — and tell me why. I build the B version for a living.
0 voted
1%
0 voted
1%
0 votes
Closed
I engineered a hybrid-rendered Next.js 15 frontend leveraging Incremental Static Regeneration (ISR) to absorb repeat traffic at the edge, reducing public GET requests to near zero. The core system is powered by a custom Node.js/Express REST API, containerized with Docker and deployed for auto-scaling on Google Cloud Run. To bridge the cached frontend with the dynamic CMS, I implemented an on-demand ISR webhook. This allows admins—secured via stateless HttpOnly JWT cookies—to publish updates that instantly bypass the cache and go live globally in seconds.
The publish flow is the part I'd show a client. An editor updates the CMS once, and the page refreshes worldwide in seconds without a developer touching it.