How we scaled the GitHub API with a sharded, replicated rate limiter in Redis
In this technical retrospective (2021), @pimterry shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Pandemic Bubble (2020–2022)
COMMUNITY SCORE 4 points
TOTAL DISCUSSIONS 3 comments
The issue with this suggested implementation that it's not atomic and might cause some race conditions.
``` local expires_at = tonumber(redis.call("get", expires_at_key)) if not expires_at or expires_at < current_time then -- this is either a brand new window, -- or this window has closed, but redis hasn't cleaned up the key yet -- (redis will clean it up in one more second) -- initialize a new rate limit window redis.call("set", rate_limit_key, 0) redis.call("set", expires_at_key, next_expires_at)
``` Between the time the `get` is called and the `set` is called there might parallel call that might create the key and the `set` will override it.