Indexing for Performance: Primary vs Secondary Indexes

Most developers only learn this for exams… not for real systems 👇 ER Model ≠ Relational Model ER Model → conceptual view of data (entities, relationships, attributes) 🧠 Relational Model → actual implementation in tables (rows, columns, keys) 🗄️ When building real systems, you don’t just design ER diagrams — you translate them into relational schemas using rules like: strong entities → tables, weak entities → composite keys, multivalued attributes → separate tables, and relationships → foreign keys. This is where many devs struggle ⚠️ because a good schema isn’t just “converted” — it’s designed for consistency, scalability, and query performance. This small distinction changes how you design systems. Building systems > memorizing concepts 🚀 What’s one concept developers often misunderstand? 🤔 #fullstackdeveloper #softwareengineering #webdevelopment #javascript #reactjs #backend #buildinpublic

“set (𝙧𝙚𝙫𝙖𝙡𝙞𝙙𝙖𝙩𝙚: 𝟲𝟬) and move on” This works in Next.js — until it doesn’t. Now you’re: • serving stale data for up to 60s • re-fetching even when nothing changed • adding load for no reason This is where caching stops being an optimization — and becomes about 𝘄𝗵𝗼 𝗼𝘄𝗻𝘀 𝗳𝗿𝗲𝘀𝗵𝗻𝗲𝘀𝘀. At a high level: 𝗦𝘁𝗮𝘁𝗶𝗰 𝗿𝗲𝗻𝗱𝗲𝗿𝗶𝗻𝗴 → speed 𝗗𝘆𝗻𝗮𝗺𝗶𝗰 𝗿𝗲𝗻𝗱𝗲𝗿𝗶𝗻𝗴 → freshness 𝗖𝗮𝗰𝗵𝗶𝗻𝗴 + 𝗿𝗲𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗶𝗼𝗻 → where we balance the two But this abstraction starts to break down at scale. 👉 𝗧𝗶𝗺𝗲-𝗯𝗮𝘀𝗲𝗱 𝗿𝗲𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗶𝗼𝗻 (𝗿𝗲𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗲) periodically refetches data This works well when data becomes stale in predictable intervals Think dashboards, blogs, or analytics snapshots 👉 𝗢𝗻-𝗱𝗲𝗺𝗮𝗻𝗱 𝗿𝗲𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗶𝗼𝗻 (𝗿𝗲𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗲𝗧𝗮𝗴, 𝗿𝗲𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗲𝗣𝗮𝘁𝗵) flips the model Don't blindly revalidate — react to change In one of our systems, moving from time-based to event-driven invalidation: • reduced redundant fetches significantly • cache behavior became predictable under load This becomes the default once writes are frequent. 👉 𝗙𝘂𝗹𝗹 𝗥𝗼𝘂𝘁𝗲 𝗖𝗮𝗰𝗵𝗲 𝘃𝘀 𝗗𝗮𝘁𝗮 𝗖𝗮𝗰𝗵𝗲 • Full Route Cache → caches the rendered output • Data Cache → caches the underlying fetch calls That separation is powerful: Don't rebuild the entire page — refresh just the data 🧠 𝗠𝘆 𝘁𝗮𝗸𝗲𝗮𝘄𝗮𝘆 𝗦𝘁𝗼𝗽 𝘁𝗵𝗶𝗻𝗸𝗶𝗻𝗴 𝗶𝗻 𝘁𝗶𝗺𝗲 → 𝘀𝘁𝗮𝗿𝘁 𝘁𝗵𝗶𝗻𝗸𝗶𝗻𝗴 𝗶𝗻 𝗲𝘃𝗲𝗻𝘁𝘀 Instead of → “𝘳𝘦𝘷𝘢𝘭𝘪𝘥𝘢𝘵𝘦 𝘦𝘷𝘦𝘳𝘺 𝘟 𝘴𝘦𝘤𝘰𝘯𝘥𝘴” Think → “𝘸𝘩𝘢𝘵 𝘦𝘷𝘦𝘯𝘵 𝘴𝘩𝘰𝘶𝘭𝘥 𝘮𝘢𝘬𝘦 𝘵𝘩𝘪𝘴 𝘥𝘢𝘵𝘢 𝘴𝘵𝘢𝘭𝘦?” ❓Interested to hear how this plays out in write-heavy or multi-region setups. #NextJS #Caching #ReactJS #WebDevelopment #FullStack #JavaScript #SoftwareEngineering #SystemDesign #FrontendDevelopment

You don’t fix a messy database by just breaking tables. You fix it by understanding why data becomes messy in the first place 👇 Normalisation is a technique. Functional Dependency is the logic behind it. If you skip FD, you’re just guessing your schema. Normalisation ≠ Functional Dependency Normalisation → Organizing tables to reduce redundancy Functional Dependency → Defining how one attribute depends on another When building real systems, you don’t just use Normalisation — you rely on Functional Dependency to handle data consistency and prevent anomalies. Example: UserID → Email If you store Email in multiple places despite this dependency, you’ll face: - update anomalies - deletion issues - inconsistent data ⚠️ Armstrong’s Axioms (Reflexive, Augmentation, Transitivity) are not just theory — they help you reason about how your data should behave. 1NF, 2NF, 3NF, BCNF are results. Functional Dependency is the foundation 🧠 This small distinction changes how you design systems. Building systems > memorizing concepts 🚀 What’s one concept developers often misunderstand? #fullstackdeveloper #softwareengineering #webdevelopment #javascript #reactjs #backend #buildinpublic #nodejs #nextjs #typescript

I added indexes… and my API got slower. Yes, slower. For the longest time, I believed: “Indexes = faster performance” Turns out — that’s only half the truth. Under the hood, databases use B+ Trees for indexing. They make reads faster by avoiding full table scans. But here’s what no one tells you. Every time you: → INSERT → UPDATE → DELETE Your database has to update every relevant index too. So when you keep adding indexes thinking you're optimizing…... You’re actually: → Slowing down writes → Increasing storage → Hurting performance at scale I learned this the hard way after indexing almost every column. Reads improved slightly — but write latency shot up, and the system struggled under load. So what actually works? Use indexes when: ✔ You’re filtering (WHERE) ✔ You’re sorting (ORDER BY) ✔ You have heavy read traffic Avoid them when: ✖ Column has low uniqueness (like boolean/status) ✖ Writes are frequent ✖ You’re “just trying to optimize everything” Indexes are not an optimization. They’re a trade-off. And most developers overuse them. Curious — have you ever seen indexes backfire in your projects? Or do you still think “more indexes = better performance”? 👇 Drop your experience or take below #SoftwareEngineering #BackendDevelopment #DatabaseDesign #DatabaseOptimization #SystemDesign #PerformanceEngineering #ScalableSystems #NodeJS #WebDevelopment #TechArchitecture #CodingBestPractices #DeveloperLife

Have you ever found yourself struggling with data formats in JavaScript? JSON.parse and JSON.stringify are your best friends when it comes to converting data to and from JSON format. ────────────────────────────── Mastering JSON.parse and JSON.stringify Unlock the full potential of JSON in your JavaScript projects. #javascript #json #webdevelopment ────────────────────────────── Key Rules • Use JSON.stringify to convert JavaScript objects into JSON strings. • Use JSON.parse to turn JSON strings back into JavaScript objects. • Be mindful of data types; functions and undefined values cannot be stringified. 💡 Try This const obj = { name: 'Alice', age: 25 }; const jsonString = JSON.stringify(obj); const parsedObj = JSON.parse(jsonString); console.log(parsedObj); ❓ Quick Quiz Q: What does JSON.stringify do? A: It converts a JavaScript object into a JSON string. 🔑 Key Takeaway Mastering JSON methods can simplify data handling in your applications! ────────────────────────────── Small JavaScript bugs keep escaping to production and breaking critical user flows. Debugging inconsistent runtime behavior steals time from feature delivery.

😅 I once changed a value in a “copied” object…... and somehow the original data changed too 💥 👉 That’s when I realized… I didn’t understand shallow vs deep copy properly. 🚀 Let’s break it down (this will save you from real bugs) 🧠 Why this matters In JavaScript, objects & arrays are reference types So copying them incorrectly = you might accidentally modify the original data 😬 📦 1. Shallow Copy A shallow copy only copies top-level values 👉 Nested objects are still shared (same reference) So: - Changing top-level → ✅ safe - Changing nested → 💥 affects original too ⚠️ The common mistake You think you created a new object… but deep inside, it’s still pointing to the same memory 😵 🔁 How to create shallow copy • Spread → {...obj} • Object.assign • Array methods → slice, Array.from 🔐 2. Deep Copy A deep copy creates a fully independent clone 👉 Every level is copied 👉 No shared references So: - Changing nested data → ✅ completely safe 🔁 How to create deep copy 👉 structuredClone() (Recommended) - Handles most data types - Modern & reliable 👉 JSON.parse(JSON.stringify()) - Quick but limited - loses functions, Dates, undefined 💡 Real Dev Insight Shallow copy is fast ⚡ Deep copy is safe 🛡️ 👉 Use shallow → for simple data 👉 Use deep → for nested structures 🚀 Final Thought: Most bugs don’t come from logic… 👉 They come from unexpected mutations Understand copying → write safer code 💪 #JavaScript #FrontendDevelopment #WebDevelopment #CodingTips #ShallowCopy #DeepCopy #LearnJavaScript #BuildInPublic #100DaysOfCode #LearnInPublic

Your database is lying to you… and you don’t even know it 👀 Most bugs in production aren’t because of bad queries — they happen because your transactions aren’t designed right ⚠️ And once data breaks, you can’t “debug” it easily 🔥 Transaction ≠ ACID Properties Transaction → A logical unit of work executed in sequence 🧩 ACID Properties → Rules that guarantee your data won’t break under real-world conditions 🛡️ When building real systems, you don’t just use transactions — you rely on ACID to handle consistency, concurrency, and failure scenarios ⚙️ Atomicity → All or nothing (no partial updates) 💥 Consistency → Data stays valid before and after execution ✅ Isolation → Parallel transactions don’t mess with each other 🔒 Durability → Once saved, always saved (even after crashes) 💾 Here’s where most devs mess up ↓ You think “my query works” = system is correct ❌ But in production: – Multiple users hit your DB at the same time 🌍 – Network failures happen 🌐 – Partial writes can corrupt data 💣 That’s where transaction states matter: Active → Queries are running ⚡ Partially Committed → Changes are in memory (not permanent yet) 🧠 Committed → Changes are safely stored 📦 Failed → Something broke mid-way ❗ Aborted → Rollback happened, DB restored 🔄 Terminated → Transaction is done (success or failure) 🏁 This small distinction changes how you design systems. You stop thinking in queries… and start thinking in failure scenarios 🧠 Building systems > memorizing concepts 🚀 What’s one concept developers often misunderstand? 🤔 #fullstackdeveloper #softwareengineering #webdevelopment #javascript #reactjs #backend #buildinpublic #nodejs #nextjs #typescript

Day 5: Beyond Static Pages — Achieving the Full CRUD Cycle 📈 Today was a major milestone in my #100DaysOfCode journey. My Micro-Market Dashboard has officially transitioned from a "display tool" to a functional application. I successfully implemented Update functionality, completing the full CRUD (Create, Read, Update, Delete) cycle. This was an intense exercise in managing application state and data integrity. Key Technical Highlights: 🔄 State-Driven UI: I built logic that allows the sidebar form to toggle dynamically between "Add Mode" and "Edit Mode" based on a global index. 💾 Data Integrity: Used LocalStorage to ensure that even after an edit and a page refresh, the vendor data remains accurate and persistent. ✨ UI Polish: Used Tailwind CSS to handle the alignment challenges that come with dynamic forms, ensuring the UX stays clean regardless of the mode. What’s Next? Now that I’ve mastered client-side persistence, I’m ready to bridge the gap to the backend. Next stop: MongoDB! 🚀 🔗 Check the live progress: https://lnkd.in/gn6FEDTJ #BCA #IGNOU #MERNStack #SoftwareDevelopment #WebDesign #Javascript #BuildingInPublic

🚀 What is JSON? (Explained Simply) In today’s digital world, applications are constantly communicating with each other. But how do they actually exchange data so efficiently? That’s where JSON (JavaScript Object Notation) comes in. JSON is a lightweight data format used to store and exchange data between systems—especially between servers and web applications. Think of it as a simple, structured way to represent data using text. 🔍 Why JSON is so powerful: ✔️ Easy for humans to read and write ✔️ Easy for machines to parse and generate ✔️ Built using simple key–value pairs 📦 Example: { "name": "Alice", "age": 25, "isStudent": false, "skills": ["Python", "JavaScript"] } 🧠 Key Concepts: • Objects → Wrapped in {} (like dictionaries) • Arrays → Wrapped in [] (lists of values) • Keys → Always strings (in quotes) • Values → Can be strings, numbers, booleans, arrays, objects, or null 🌐 Where is JSON used? 🔹 APIs (sending & receiving data) 🔹 Configuration files 🔹 Databases 🔹 Modern web applications JSON might look simple at first glance, but it’s one of the core building blocks behind almost every modern application you use today. Mastering JSON is not optional anymore—it’s essential. 💡 Follow for more simple explanations of tech concepts. #JSON #WebDevelopment #APIs #Programming #JavaScript #FullStack #TechExplained #Developers #CodingBasics #SoftwareDevelopment #nikhil

𝗖𝘂𝗿𝘀𝗼𝗿 𝘃𝘀 𝗢𝗳𝗳𝘀𝗲𝘁 𝗣𝗮𝗴𝗶𝗻𝗮𝘁𝗶𝗼𝗻 𝗪𝗵𝘆 𝗬𝗼𝘂𝗿 𝗔𝗣𝗜 𝗡𝗲𝗲𝗱𝘀 𝗮𝗻 𝗨𝗽𝗴𝗿𝗮𝗱𝗲 If you're still using offset pagination… your API might already be slowing down Offset Pagination (The Old Way) 𝘎𝘌𝘛 /𝘶𝘴𝘦𝘳𝘴?𝘱𝘢𝘨𝘦=3&𝘭𝘪𝘮𝘪𝘵=10 Looks simple, but:  • Gets slower as data grows  • Can return duplicate or missing records  • Breaks when data updates in real-time Cursor Pagination (The Upgrade) 𝘎𝘌𝘛 /𝘶𝘴𝘦𝘳𝘴?𝘤𝘶𝘳𝘴𝘰𝘳=𝘢𝘣𝘤123 Instead of pages, it uses a reference point (cursor). Why Cursor Pagination Wins  • Faster queries (no row skipping)  • Consistent results  • Scales to millions of records  • Perfect for feeds, chats, notifications If you're building: Infinite scroll Notifications Real-time apps  𝗢𝗳𝗳𝘀𝗲𝘁 𝗽𝗮𝗴𝗶𝗻𝗮𝘁𝗶𝗼𝗻 𝗶𝘀 𝗮 𝗯𝗮𝗱 𝗰𝗵𝗼𝗶𝗰𝗲. Final Thought Offset pagination is easy. Cursor pagination is what production systems use. If your app is growing… this upgrade is not optional anymore. #Backend #API #SystemDesign #WebDevelopment #Scalability #NodeJS #Database #SoftwareEngineering #NestJS #ExpressJS #FullStack #Frontend #Angular #ReactJS #Microservices #DistributedSystems #CloudComputing #Performance #AI #AIAgents #AIEngineering #WebArchitecture #RemoteWork #TechJobs #Developers #Coding