The latest articles on Forem by Abhay Ojha (@abojha404). https://forem.com/abojha404 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3473872%2Fa3d4b614-f947-4b55-a5bd-9b1c7e56e8fe.jpg https://forem.com/abojha404 en Abhay Ojha Fri, 03 Apr 2026 10:40:34 +0000 https://forem.com/abojha404/when-scaling-broke-my-system-and-it-wasnt-a-performance-issue-5g83 https://forem.com/abojha404/when-scaling-broke-my-system-and-it-wasnt-a-performance-issue-5g83 <p>Recently, I scaled a system from a small dataset to thousands of files.</p> <p>And everything broke.</p> <ul> <li>Storage usage exploded </li> <li>Queries became painfully slow </li> <li>Even simple operations started timing out </li> </ul> <p>At first, I assumed it was a performance issue.</p> <p>It wasn’t.</p> <p>It was an architectural mistake.</p> <h2> What went wrong </h2> <p>Without realizing it, I had turned a vector database into a full data storage system.</p> <p>Instead of using it just for similarity search,<br> I was relying on it for:</p> <ul> <li>storing large structured data </li> <li>handling exact queries </li> </ul> <p>And that’s where things started to fall apart.</p> <h2> What I learned </h2> <p>Vector databases are great at:</p> <ul> <li>finding relevant or similar information </li> </ul> <p>But they are not designed for:</p> <ul> <li>storing large structured datasets </li> <li>handling precise, exact-match queries at scale </li> </ul> <h2> The fix: a hybrid approach </h2> <p>I changed the system design to separate concerns:</p> <ul> <li>one layer for semantic search (vector DB) </li> <li>one layer for exact retrieval (traditional database) </li> </ul> <p>This made the system:</p> <ul> <li>faster </li> <li>more predictable </li> <li>easier to scale </li> </ul> <h2> Key takeaway </h2> <p>Scaling isn’t just about handling more data.</p> <p>It’s about using the right system for the right job.</p> <p>Sometimes, the biggest optimization isn’t in the code.</p> <p>It’s in the architecture.</p> systemdesign database vectordatabase ai Abhay Ojha Fri, 03 Apr 2026 10:31:23 +0000 https://forem.com/abojha404/small-bugs-arent-always-about-coding-3ph3 https://forem.com/abojha404/small-bugs-arent-always-about-coding-3ph3 <p>I’ve noticed something interesting while working on bugs.</p> <p>Most of the time, the issue isn’t that the code is complex.</p> <p>It’s that the requirements were never clear in the first place.</p> <p>The logic exists in our head,<br> but not in the code or documentation.</p> <h2> A simple habit that helps </h2> <p>Before jumping into coding, try spending 10 minutes writing things down.</p> <p>Just basic points:</p> <ul> <li>What exactly are we building?</li> <li>What are the non-goals?</li> <li>What does success look like?</li> <li>What edge cases might break this?</li> <li>How will this be rolled out?</li> </ul> <h2> Why this works </h2> <p>This small step forces clarity early.</p> <p>It helps:</p> <ul> <li>catch gaps in understanding </li> <li>reduce back-and-forth during reviews </li> <li>avoid unnecessary debugging later </li> </ul> <h2> Curious to know </h2> <p>Do you usually write things down before coding,<br> or do you prefer figuring things out while building?</p> programming webdev productivity beginners