Building ED-DRLE: A Distributed Reservation Ledger, and What I Got Wrong Before I Got It Right

Tejas H — Mon, 07 Sep 2026 17:23:35 +0000

Reservation systems look deceptively simple on the surface—check availability, hold a slot, and confirm a booking. But underneath, they're one of the more honest tests of distributed systems thinking: multiple services need to agree on state, failures happen mid-transaction, and "just use a database lock" stops working the moment you scale past a single node.

ED-DRLE (Distributed Reservation Ledger) is my attempt to build that system properly—not as a toy CRUD app with a reservations table, but as a system that survives partial failure, avoids double-booking under load, and is honest about where it still falls short.

This post walks through the architecture, the trade-offs, and—just as importantly—the gaps I found in my own design when I held it up against a real target load.

The Core Problem:

A reservation isn't a single write. It's a sequence: check availability → hold the resource → charge or confirm → finalize. If any step fails partway, you can't just roll back with a database transaction, because the steps span multiple services and, in a real system, multiple data stores.

This is the classic distributed transaction problem, and it's why ED-DRLE is built around the Saga pattern instead of two-phase commit.

Why Saga Over 2PC:

Two-phase commit gives you strong consistency, but it does so by holding locks across services until every participant agrees to commit—which means one slow or failed service blocks everyone else. For a reservation system under real traffic, that's a latency and availability risk I wasn't willing to take on.

Sagas trade strict atomicity for a sequence of local transactions, each with a defined compensating action if a later step fails. If a hold succeeds but the confirmation step fails, the system runs a compensating transaction to release the hold—instead of everyone waiting on a coordinator.

I used AWS Step Functions to orchestrate the saga steps explicitly, rather than hand-rolling a choreography-based saga with event chains. This made the failure paths visible and testable as a state machine, rather than implicit in a web of service-to-service events.

Storage: Redis-to-DynamoDB Tiering

Reservation holds are short-lived and high-frequency—perfect for an in-memory store, but not something you want as your durable source of truth. ED-DRLE uses a tiered persistence model:

Redis holds active reservation locks and short-TTL holds, optimized for fast reads/writes under contention.
DynamoDB persists confirmed reservations durably, once a hold survives the saga's confirmation step.

This keeps the hot path fast without giving up durability for the state that actually matters long-term.

Protecting the System Under Load:

Two mechanisms sit in front of the core reservation logic:

Token-bucket rate limiting, to prevent a burst of requests for the same resource from overwhelming the hold logic
A circuit breaker, so that if a downstream dependency (e.g., the confirmation service) starts failing, the system stops hammering it and fails fast instead of piling up retries

Neither of these is exotic, but both are the difference between a system that degrades gracefully and one that falls over in a cascading failure.

What the Numbers Actually Say:

I load-tested ED-DRLE at 229 RPS, with a p95 latency of 315 ms. I'm stating these numbers plainly rather than rounding them up or extrapolating to a bigger number, because the honest baseline is more useful—to me and to anyone reading this—than an inflated one.

That number matters because I evaluated it against a 10,000 RPS target I set for the system's design, and it's not close yet. That gap is the most useful part of this project, not the part I'd normally put in a portfolio blurb.

Where the System Still Has Gaps:

I analyzed the design against that 10,000 RPS target, deliberately looking for what would break, rather than assuming the architecture was sound because it worked at moderate load. Four gaps stood out:

No expiry reconciliation between Redis and DynamoDB. If a Redis hold expires but the corresponding DynamoDB state isn't reconciled, the two stores can drift out of sync—a real correctness risk, not just a performance one.
Non-idempotent compensating transactions. Saga compensations need to be safely retryable. Right now, a retried compensation isn't guaranteed to be a no-op if it's already been applied, which risks double-compensating (e.g., releasing a hold twice).
No RDS proxy in front of the relational layer. At higher connection volumes, this becomes a real bottleneck—connection exhaustion under a traffic spike is a predictable failure mode without it.
An unbounded Redis set. Without a cap or eviction policy, this is a slow-building memory risk under sustained load—the kind of thing that looks fine in a load test and fails quietly in production weeks later.

None of these are hidden in the codebase—they're the direct output of stress-testing the design against a target an order of magnitude higher than what I've actually measured.

Why I'm Writing This Instead of Just Shipping It

It would be easy to describe ED-DRLE as "a distributed reservation system built with Saga orchestration, Redis, and DynamoDB" and leave it there. But the more useful engineering story is the second half: what happens when you take your own architecture seriously enough to look for where it breaks.

229 RPS at p95 315 ms is a real, measured number—not a projection, not a "should scale to." And the four gaps above are the actual next milestones for this project, not a hidden list I'm keeping to myself.

If you're working on anything with a similar shape—sagas, tiered storage, rate limiting under real load—I'd genuinely like to compare notes on where your design held up and where it didn't.

GitHub-https://github.com/Tejas-h-blitz/Aws-Distributed-Reservation-Ledger

Solo Build Challenge: How I Built Beacon AI for HACKHAZARDS '26

Tejas H — Wed, 17 Jun 2026 15:04:25 +0000

When preparing for placements and technical interviews, most students face a major roadblock: generic AI tools give flat advice, and mock interviews with real people are hard to schedule.
To solve this, I decided to join HACKHAZARDS '26 as a solo developer and build Beacon AI—a complete, full-stack AI career ecosystem designed to help students bridge the gap between college and their dream tech roles.

🚀 The Core Features I Shipped
Instead of creating a simple chatbot wrapper, I engineered three distinct functional modules entirely on my own:

Interactive AI Interview Coach: A real-time simulator where users answer technical questions and get instant, structured feedback on their performance.
Skill Gap Analytics Dashboard: A visual interface that tracks user progress, highlights weak areas, and points out missing skills for specific industry roles.
Automated Resume Builder: A structured tool that helps users organize their professional details and checks if their background matches current market standards.

🛠️ My Technology Stack
To ensure the application runs fast and manages user data properly, I chose a decoupled, full-stack architecture:
Frontend & Server Layers: Built with Next.js (App Router) and styled using Tailwind CSS and Shadcn UI for a clean, professional user experience.
Database Persistence: I integrated Prisma ORM connected to a relational database to keep user metrics, scores, and historical profiles completely active.
AI Microservice Backend: A dedicated FastAPI (Python) server running LangChain and the Google Gemini API to handle structured prompt processing and smooth token generation.

📂 Project Architecture
To keep the codebase clean and ready for judge code reviews, I organized the repository into explicit folders:
├── /app # Next.js frontend pages and layouts
├── /actions # Server actions for database operations
├── /python-backend # FastAPI server for LangChain & Gemini AI
├── /components # Reusable UI elements via Shadcn UI
├── /data # Static data configurations (FAQs, guides)
└── /lib # Prisma Client setup and utilities

⚡ Challenges I Faced & My Solo Fixes

Managing the Dual-Service Pipeline Alone Building both a JavaScript frontend framework and a Python backend microservice simultaneously during a hackathon can get messy quickly. The Fix: I carefully isolated the AI logic inside FastAPI. This allowed me to manage API requests efficiently and pass structured data back to the Next.js client using server actions without locking up the client interface.
Ensuring Data Integrity Across Sessions I wanted to ensure this felt like a real SaaS product, meaning data could not just vanish on a page refresh. The Fix: I set up Prisma ORM early in the development cycle. Every mock interview score and skill assessment is written securely to the database, ensuring a user's progress history is completely saved. ** 🏁 Conclusion** Taking on HACKHAZARDS '26 as a single solo developer was a massive challenge, but it pushed me to move away from simple prototypes and master a true production-ready stack. The application is fully live and ready to run!

Check out the project here:

🔗 Live Application: https://beacon-ai-blitz.vercel.app/
💻 GitHub Repository: https://github.com/Tejas-h-blitz/Beacon-AI

Built with ❤️ by a solo hacker for the Namespace Community.

DEV Community: Tejas H

Building ED-DRLE: A Distributed Reservation Ledger, and What I Got Wrong Before I Got It Right

Solo Build Challenge: How I Built Beacon AI for HACKHAZARDS '26