Latest updates

Recently explored idempotency through Arpit Bhayani’s explanation and implemented a backend system to understand how it works in practice. Built a REST API using Node.js, Redis, and MongoDB to ensure that repeated requests don’t lead to duplicate operations — a critical requirement in systems like payments and order processing. 🔧 What I implemented: • Idempotency key handling at the API layer • Redis-based response caching for repeated requests • Distributed locking to manage concurrent execution • Request hashing to validate retry consistency • Handling of in-flight requests (processing state) • Dockerized setup for a consistent environment 💡 Key learnings: • Designing for safe retries requires control over system state, not just endpoints • Preventing race conditions needs both locking and state awareness • Redis can act as a coordination layer, not just a cache • Request validation and hashing are important for maintaining data integrity • Docker helps simulate production-like behavior early This project helped me better understand how backend systems maintain consistency and reliability under retries, failures, and concurrent requests. Happy to hear feedback or suggestions.

Explored REST vs GraphQL by building and then extending a backend system step by step. I wanted to better understand the practical difference between REST and GraphQL beyond just theory, so I built a small Notes backend using FastAPI where both APIs work on the same data model. The idea was simple: -Use REST endpoints and observe how data is fetched -Use GraphQL on the same system and compare flexibility and response structure Some things became clearer while building: -REST works well but tends to return fixed responses -GraphQL allows querying only the required fields, especially useful for nested data -Fetching related data in REST can require multiple calls, while GraphQL handles it in a single query.[images below shows the difference] After getting this basic comparison working, I extended the project to make it closer to a real backend: -Added Prisma ORM with SQLite for persistence -Implemented JWT-based authentication for user-specific access -Integrated WebSockets to broadcast updates in real-time For example, when a section is added to a note, all connected clients receive the update instantly. This started as a small exploration but turned into a good learning experience around API design, data fetching patterns, and real-time systems. GitHub: https://lnkd.in/dBD-HSiy Open to feedback.

A simple question got me thinking: “How do real APIs decide when to stop serving requests?” Ended up building a small system to explore it. Instead of using libraries, I implemented a rate limiter from scratch using Node.js + Redis — just to understand what actually happens under the hood. What made it interesting wasn’t the code, but the edge cases: -Same user vs multiple users → different Redis keys -Guest vs authenticated → completely different limits -Token issues → system silently falling back to guest -Middleware order → breaking the entire logic without errors Eventually built: • IP-based limiting (guests) • User-based limiting (JWT) • Tier-based control (free vs premium) • Sliding window using Redis Sorted Sets • Proper rate limit headers (so clients can self-regulate) What I didn’t expect: The problem is less about “blocking requests” and more about “how to do it fairly and efficiently under concurrency.” Still a lot to improve (atomic operations, route-based limits), but this was a solid step toward understanding backend systems. If you’ve worked on something similar, curious how you handled race conditions. GitHub:https://lnkd.in/dQ9TWM_p

Job hunting is frustrating. Not because there aren't enough opportunities, but because every application expects a resume and cover letter tailored to it. Doing that properly takes 30–45 minutes. So most of us (me included) end up sending the same resume everywhere — and it shows. I'm building something to fix that. Job Application AI Agent The goal isn't to replace the applicant. It's to remove the repetitive work while keeping the final decision in human hands. What it does today: - Paste a job URL - Agent reads the JD, compares it against my resume + GitHub projects (via the GitHub REST API) - Generates a tailored resume, a personalized cover letter draft, missing-skill gaps, and application tips - I review every change (before/after diff, per bullet) before anything is used One design decision I'm not compromising on: it will never auto-apply. A lot of tools mass-submit applications to save time — that lowers quality and risks getting accounts flagged. My approach for this application : AI prepares. Human decides. The hardest part so far wasn't the AI — it was the PDF. My resume is LaTeX. My first compiler (Tectonic) crashed with no useful error, on both Windows and Linux, and only when a FontAwesome icon package was in the doc. Took a day of isolating a minimal repro to find it was a real compiler bug, not my code. Switched to a sandboxed Docker + TeX Live pipeline instead — that's the boring-but-correct lesson :- Sometimes the fix isn't smarter code, it's a different tool. I also built an eval harness before trusting any model with real resumes — deterministic checks + an LLM judge + A/B testing across models, so I could pick one on evidence (accuracy, hallucination rate, cost) instead of vibes. Tech stack: Python, LangGraph, FastAPI, Next.js, OpenRouter (Gemini), GitHub REST API, Docker, SQLite. What's next: • Scheduled job discovery (Greenhouse & Lever public APIs) • AI fit-ranking across jobs • Application history & tracking I'll keep sharing both the wins and the breakages as I build this. If you could add one feature to an AI job-application assistant, what would it be? Your answer might shape the next update. Github :- https://lnkd.in/dPZX-fKJ

Job hunting is broken. Every application expects a tailored resume and cover letter, but doing it properly takes 30–45 minutes. So I'm building an AI agent that removes the repetitive work—without taking humans out of the loop.