Why System Design Matters on Build Day
Round 3 is where AlgoNation stops being a purely individual algorithmic exercise and turns into something much closer to real engineering work. Teams get a real-world problem statement at the start of an eight-hour, in-person build day, and they're judged not just on whether the demo works, but on system design, code quality, problem fit, team execution, and demo clarity. Of those, system design carries the single largest weight in our judging rubric — thirty percent — because it's the clearest signal of whether a team understood the problem deeply enough to build something that could plausibly survive contact with real users, not just survive a demo.
The good news is that the patterns judges are actually looking for are a fairly small, well-known set. You don't need to design something that could handle Google-scale traffic in eight hours — you need to show that you understand the tradeoffs involved and can articulate why you made the choices you did. Here are the five patterns that come up again and again across past Round 3 problem statements, and how to actually apply them under a tight build-day clock.
1. Rate Limiting
Almost any problem statement involving a public-facing API or a shared resource benefits from an explicit rate-limiting story, even a simple one. Judges don't expect a distributed token-bucket implementation running across multiple nodes — they expect you to recognise that unrestricted access to a resource is a design flaw, and to implement something proportionate. A basic in-memory sliding window counter per user or per IP, clearly explained, is often enough to earn full credit here. What matters is that you can explain the tradeoff: why you chose the limit you chose, and what happens to a request once the limit is hit.
2. Caching
Caching is probably the single highest-leverage pattern to have ready for Round 3, because it does double duty: it improves your actual demo's responsiveness under judge testing, and it's an easy, concrete thing to point to when judges ask about your architecture. Identify the one or two most expensive or frequently repeated operations in your system — a database query, an external API call, a computed aggregation — and cache the result with a sensible expiry. Be ready to explain your cache invalidation strategy in one sentence; 'we don't have one' is a much weaker answer than 'we invalidate on write' or 'we use a short TTL because staleness here is acceptable for a few seconds.'
3. Load Balancing
You almost certainly won't be running multiple production instances of your service during an eight-hour build day, and judges know that. What they're testing here is conceptual understanding, not deployment reality. Be ready to describe, even hypothetically, how your system would scale horizontally if traffic grew — what would need to become stateless, where session data would need to move, and what a simple round-robin or least-connections strategy would look like in front of your service. A single clear paragraph in your presentation covering this is worth more than an over-engineered attempt to actually spin up multiple instances and lose build time doing it.
4. Eventual Consistency
Any problem statement involving multiple services, asynchronous updates, or data that's read far more often than it's written is a strong candidate for an eventual consistency story. The key insight judges are listening for is that you understand the difference between strong and eventual consistency, and that you made a deliberate choice rather than defaulting to whatever was easiest to code. If your system shows a slightly stale view of data for a few seconds after a write — a follower count, a leaderboard, an aggregated stat — say so explicitly, and explain why that tradeoff is acceptable for your specific use case. Pretending your system is perfectly consistent when it obviously isn't reads as a gap in understanding, not a strength.
5. Asynchronous Processing & Message Queues
Any operation that's slow, unreliable, or not required to complete before you respond to the user — sending an email, processing an uploaded file, generating a report — is a candidate for pulling out of the request path entirely. Even a lightweight in-process job queue, or a simple background worker polling a table for pending tasks, demonstrates the right instinct: keep your user-facing response fast, and let slow work happen out of band. This pattern is especially valuable in Round 3 because it directly improves your live demo's perceived speed, which judges notice immediately when they're testing your product themselves.
How Judges Actually Evaluate This
It's worth repeating what we tell every mentor working Round 3: judges are not looking for the most technically sophisticated architecture in the room. They're looking for evidence of deliberate tradeoffs, clearly explained. A team that built a simple system and can articulate exactly why each choice was made will consistently outscore a team that bolted on complexity they can't defend under questioning. When you're presenting, don't just describe what you built — describe what you chose not to build, and why, given an eight-hour constraint and the specific problem in front of you.
Bonus Pattern: Idempotency
It doesn't always make the headline list of system design patterns, but idempotency comes up constantly in Round 3 problem statements involving payments, submissions, or any operation a user might accidentally trigger twice — a double-click on a submit button, a retried network request, a form resubmission after a page refresh. The pattern itself is simple: design your write operations so that performing the same request multiple times produces the same result as performing it once, typically by having the client send a unique request identifier that the server checks against before processing. Even a basic version of this — checking whether a given order ID has already been processed before creating a duplicate — is a strong, easy-to-explain addition to a Round 3 project, and it's the kind of detail that signals real production-engineering instinct to judges without costing much build time to implement.
Documenting Your Architecture As You Go
One habit that consistently separates teams who present well from teams who fumble the system design questions in Q&A: keeping a running, informal architecture note throughout the build day, not scrambling to reconstruct one in the final thirty minutes before presentations. It doesn't need to be a formal document — a shared note or whiteboard photo listing your key components, the patterns you applied from this list, and the tradeoffs you made is enough. When a judge asks 'why did you cache this and not that,' you want an answer that's been sitting in your head since hour three of the build day, not one you're inventing on the spot under Q&A pressure. Teams that do this consistently score higher on the 'demo clarity' and 'system design' criteria simply because their explanations sound rehearsed in the good sense — confident and consistent, not improvised.
Practical Advice for Build Day Itself
Don't try to implement all five patterns from scratch under time pressure — that's a fast way to run out of build time on infrastructure instead of the actual product. Pick the two or three that are most relevant to your specific problem statement, implement them properly, and be ready to speak fluently about the others even if you didn't have time to build them. A team that says 'we'd add rate limiting here, and here's exactly how, but we prioritised build time on the core feature' scores better than a team that either ignores the topic entirely or claims to have built something they clearly rushed.
If you want hands-on practice with these patterns before Round 3, our System Design Fundamentals workshop — run by a Staff Engineer from Razorpay — walks through all five with live examples, and it's free for every registered participant. Combine that with a boilerplate repo you've prepped in advance (auth, a basic API, a database connection already wired up) so you're not burning build-day hours on scaffolding, and you'll walk into Round 3 with real bandwidth to focus on the design decisions that actually earn points.
Preparing Your Boilerplate Before August 30
The single most effective thing a team can do in the days before Round 3 has nothing to do with any individual pattern on this list — it's showing up with a working boilerplate already in place. Agree as a team, before build day, on your stack: which framework for the frontend, which backend language and framework, and which database. Have a repository already scaffolded with basic authentication, a health-check endpoint, and a database connection that you know works, so that the moment your problem statement is revealed at 9:00 AM, your team is writing feature code, not debugging a fresh project setup. Teams that walk in with this groundwork consistently report having an extra one to two hours of genuine build time compared to teams starting completely from scratch, and in an eight-hour window, that's often the exact margin between a team that gets to properly apply two or three of the patterns above and a team that runs out of time before they can implement any of them cleanly.