Forem: muskan thakur

Why Your App Can't Have It All: The CAP Theorem Explained for Dev Teams

muskan thakur — Thu, 10 Apr 2025 09:11:15 +0000

Inspired by my recent read of the incredible "System Design Interview" book by Alex Xu, I wanted to break down one of the most important ideas in system design in a way that actually sticks.

TL;DR

CAP Theorem says: In a distributed system, you can only choose two out of the following three guarantees:

Consistency
Availability
Partition Tolerance

So no, your dream of a system that never goes down, never returns stale data, and handles network issues like a pro? Yeah... pick two, friend.

Let's Break It Down (like a Dev Team Standup)

Imagine you and your team are building a Node.js + React app that talks to a MySQL database. You're scaling. Users are growing. You now want to go distributed. Cool? Cool.

But then... network partitions happen. Server A can't talk to Server B. 😬

Now comes the million-dollar question:

Do you want to return any data (even if it might be slightly stale)? Or do you want to wait until everything's in sync?

This is where CAP comes in.

The Three Characters in This Drama:

1. Consistency (C)

Every read returns the most recent write. No stale data. No lies.

✅ Like reading from Git main branch after every push.
❌ But this means some requests might have to wait (or fail) while the system syncs.

2. Availability (A)

Every request gets a response, even if the data isn’t the latest.

✅ Like a cached version of your dashboard that always loads.

❌ But your friend who just updated something? You might not see it yet.

3. Partition Tolerance (P)

The system continues to operate even if parts of it can’t communicate.

✅ Think of a microservice still responding even if one DB shard is out.

❌ This is non-negotiable in real distributed systems. Partitions WILL happen.

You Can Only Pick Two:

CP (Consistency + Partition Tolerance)
- Good for: Banking systems
- Bad for: Real-time chat apps
AP (Availability + Partition Tolerance)
- Good for: Social feeds, product listings, dashboards
- Bad for: Systems needing accurate, up-to-date info always
CA (Consistency + Availability)
- The unicorn. Doesn’t exist if there's a network partition. (And there will be.)

Real-World Dev Relatable Examples:

Git: Prioritizes C + A but breaks during a partition (you can't push). It sacrifices P.
MongoDB in AP Mode: Prioritizes A + P, so you might get slightly outdated reads.
Relational DB Cluster with Strong Consistency: Goes with C + P, so you may get errors during partitions but never wrong data.

What This Means for You as a Dev

If you're building:

A chat app — go for Availability (don't freeze the app if a node is down)
A banking system — go for Consistency (never allow two people to see different balances)
A content platform — go for Partition Tolerance + Availability (users won't mind a post being slightly delayed)

The smarter you are about your trade-offs, the more resilient your app becomes.

Final Takeaway

CAP isn’t just a theorem. It’s a mindset shift for devs. As you scale, you’re not just coding features — you’re negotiating guarantees.

You can have a system that does what it promises. Just don’t expect it to promise everything all at once.

Stay tuned. Or better yet, go argue with your teammates about what your app values most: C, A, or P. 😉

Plot Twist! My Life Was Teaching Me SOLID Principles All Along

muskan thakur — Wed, 29 Jan 2025 13:26:17 +0000

As developer, I’ve come to realize that coding isn’t just about writing logic—it’s about crafting something meaningful, like brewing the perfect cup of coffee or taking in a gorgeous view from a hilltop. Life itself can teach us lessons about writing better, smarter, and more adaptable code.

Let me walk you through the SOLID principles of software design, explained through some of my favorite life moments, complete with coding examples. Ready? Let’s dive in!

1. Single Responsibility Principle (SRP)

"My AeroPress is a coffee wizard. One job, one mission: making the best espresso. Simple and efficient."

In the coding world, this principle means a class, module, or function should have only one reason to change—it should do one thing and do it well.

Example:
Let’s say we’re building a task management app. Instead of dumping all the task-related logic in a single controller, we break it up.

// TaskService.js
class TaskService {
  addTask(task) {
    // Logic to add a task to the database
  }

  getTasks() {
    // Logic to fetch tasks from the database
  }
}

This way, if we ever need to change how tasks are added or fetched, we know exactly where to go. No spaghetti code here—just like my AeroPress doesn’t suddenly start making tea!

2. Open-Closed Principle (OCP)

"My balcony has amazing mountain view. The mountains never change, but the seasons add new magic—spring flowers, autumn hues, or winter snow."

This principle says your code should be open to extension but closed to modification. That means you can add new features without breaking the existing ones.

Example:
Let's imagine we are building a notification system for an app. Initially, we only support email notifications, but later, we want to add support for SMS. Instead of changing the existing code that handles email notifications, we can extend it to support new types of notifications without modifying the core logic.

// NotificationService.js

// Base class for notifications
class Notification {
  send(message) {
    throw new Error('Method "send" must be implemented');
  }
}

// Email Notification class
class EmailNotification extends Notification {
  send(message) {
    console.log(`Sending email: ${message}`);
  }
}

// SMS Notification class
class SMSNotification extends Notification {
  send(message) {
    console.log(`Sending SMS: ${message}`);
  }
}


// Notification Service that can send different notifications
class NotificationService {
  constructor(notificationStrategy) {
    this.notificationStrategy = notificationStrategy;
  }

  sendNotification(message) {
    this.notificationStrategy.send(message);
  }
}

// Example usage:
const emailService = new NotificationService(new EmailNotification());
emailService.sendNotification('Hello via Email!');

const smsService = new NotificationService(new SMSNotification());
smsService.sendNotification('Hello via SMS!');

Now, we’ve added SMS notifications without touching the email logic. The mountains (core logic) stay solid, while the seasons (new features) add flair.

3. Liskov Substitution Principle (LSP)

"At college, we had this hilltop that gave a stunning view of the campus. There were multiple paths to the top, but the view was always the same."

In coding, this means you can swap out a subclass for its parent class without breaking the functionality. It’s all about consistency.

Example:
Suppose we’re building a payment system where users can pay via credit cards or wallets.

class Payment {
  processPayment(amount) {
    console.log(`Processing payment of $${amount}`);
  }
}

class CreditCardPayment extends Payment {
  processPayment(amount) {
    console.log(`Processing credit card payment of $${amount}`);
  }
}

class WalletPayment extends Payment {
  processPayment(amount) {
    console.log(`Processing wallet payment of $${amount}`);
  }
}

function makePayment(paymentMethod, amount) {
  paymentMethod.processPayment(amount);
}

// Usage
const payment = new WalletPayment();
makePayment(payment, 100); // Works seamlessly

No matter which path (payment method) you take, the functionality (processing payment) is consistent. Just like the hilltop view was always spectacular, regardless of the path.

4. Interface Segregation Principle (ISP)

"Pookie, my cat, is an indoor queen. She needs her cozy space, while my dogs love running wild outdoors. Different needs, different designs."

This principle says don’t overload your interfaces. Each should cater to specific needs—just like Pookie wouldn’t appreciate an interface meant for the dogs.

Example:
Let’s say we’re designing APIs for pets. Instead of creating one giant API for all animals, we break it into smaller, specific APIs.

class IndoorPet {
  stayIndoors() {
    console.log("Staying indoors where it’s safe and cozy.");
  }
}

class OutdoorPet {
  roamOutside() {
    console.log("Running wild in the great outdoors!");
  }
}

// Usage
const pookie = new IndoorPet();
pookie.stayIndoors();

const dog = new OutdoorPet();
dog.roamOutside();

Each API does only what’s needed for its client. Pookie gets her cozy corners, and the dogs get their wild adventures.

5. Dependency Inversion Principle (DIP)

"Bonfires are magical! Whether it’s a small firepit or a big bonfire, it’s the warmth and connection that matter—not the fire’s size."

This principle says high-level modules shouldn’t depend on low-level details. Both should rely on abstractions.

Example:
Suppose we’re building a service to fetch user data. Instead of hardcoding a specific database, we use an abstraction layer.

class UserRepository {
  getUsers() {
    // Fetch users from the database
  }
}

class UserService {
  constructor(repository) {
    this.repository = repository;
  }

  fetchUsers() {
    return this.repository.getUsers();
  }
}

// Usage
const userService = new UserService(new UserRepository());
userService.fetchUsers();

Now, if we switch from MongoDB to MySQL, we don’t need to rewrite the service logic. The warmth (abstraction) stays constant, whether it’s a firepit or a bonfire.

Conclusion

Life’s little moments can teach us big lessons about writing better code. Whether it’s brewing coffee, enjoying a mountain view, or cuddling your cat, the principles of SOLID design are all around us.

For us developers, following these principles means cleaner, more maintainable code, happier teams, and smoother projects. So, which SOLID principle is your favorite? Got your own quirky analogy? Let’s chat in the comments!

Why React Can Surprise You (And How to Tame It)

muskan thakur — Fri, 13 Dec 2024 11:14:47 +0000

If you’ve ever worked with React, you’ve probably had moments of self-doubt. I’ve been there too—wondering if I’m missing something fundamental, only to discover that the issue wasn’t with me but with React’s peculiarities.

Here, I’ll share some of these unexpected behaviors, the reasons behind them, and my own experiences. Hopefully, this will save you some of the head-scratching I’ve endured!

1. State Updates: The Delayed Reaction

You call setState, but the UI doesn’t change immediately. Why? React batches state updates for performance. This often catches new developers off guard because it contradicts the expectation of instant feedback.

const [count, setCount] = useState(0);

const handleClick = () => {
  setCount(count + 1);
  console.log(count); // Still logs the old count
};

Why It Happens:
React’s state updates are asynchronous. This allows React to optimize re-renders, but it means that setState doesn’t immediately update count. The new state will only be reflected after the component re-renders.

Pro Tip: Use the functional form of setState to avoid relying on stale state:

setCount(prevCount => prevCount + 1);

2. Dependency Arrays in Hooks: Why Didn’t This Re-Run?

Another common pitfall: you’ve added a useEffect hook, but it doesn’t seem to run when you expect it to.

useEffect(() => {
  console.log("Effect ran");
}, [someVar]);

Then, you realize that updating someVar doesn’t trigger the effect. After debugging, you discover that someVar is an object or array.

Why It Happens:
React’s dependency array uses reference equality. Even if two objects or arrays look identical, they’re considered different if their references differ. This can lead to unexpected behavior if you’re not careful.

Pro Tip: Use a utility like useDeepCompareEffect or memoize your dependencies.

3. Re-Rendering Woes: Why Did This Re-Render?

You optimize your component, only to find it’s still re-rendering unnecessarily.

const MyComponent = ({ count }) => {
  console.log("Rendered");
  return <div>{count}</div>;
};

Even if count doesn’t change, the component re-renders because the parent component re-renders and passes a new prop reference.

Why It Happens:
React’s default behavior is to re-render child components unless you use optimizations like React.memo.

Pro Tip: Use React.memo to memoize your components or useCallback to prevent prop references from changing unnecessarily.

4. The Key Prop: What’s the Big Deal?

You forget to add a key to your list items, and suddenly your UI behaves erratically.

<ul>
  {items.map(item => (
    <li>{item}</li>
  ))}
</ul>

Why It Happens:
React uses key to track which items have changed, been added, or removed. Without unique keys, React may re-use DOM nodes incorrectly.

Pro Tip: Use unique identifiers as keys (e.g., id from your data).

5. Event Handling: The Mysterious Double Trigger

Ever had a button click event fire twice and wondered if your browser was haunted?

<button onClick={() => console.log("Clicked!")}>Click Me</button>

You click the button, and “Clicked!” shows up in the console twice in development mode.

Why It Happens:
React’s Strict Mode intentionally mounts and unmounts components twice during development to highlight potential side effects. This can cause event handlers to fire multiple times.

Pro Tip: Don't panic—it’s only in development.

6. Uncontrolled Components: Who’s in Control Here?

You create an input element and assign it a value, expecting React to manage it seamlessly, but you get a warning.

<input value="hello" />
React throws a warning about a “controlled component.”

Why It Happens:
React distinguishes between controlled components (managed by React state) and uncontrolled components (managed by the DOM). Mixing the two causes issues.

Pro Tip: Always pair value with onChange if you want a controlled component:

<input value={val} onChange={(e) => setVal(e.target.value)} />

7. Refs: Why Can’t I Just Use a Regular Variable?

You try to store a value between renders using a variable, but it resets every time.

let count = 0;

const increment = () => {
  count += 1;
  console.log(count); // Always starts from 1
};

Why It Happens:
React re-initializes variables on every render. For persistent values, use useRef:

const countRef = useRef(0);

const increment = () => {
  countRef.current += 1;
  console.log(countRef.current); // Works as expected
};

Closing Thoughts

When you know the "why," you’re not just reacting — you’re in control. React is amazing, but it can be a little confusing at times. Understanding why things work the way they do makes it way less frustrating. If you get why it's acting up, you’ll save a lot of time and frustration. It’s all part of its unique (and sometimes confusing) charm.

Dear Past Me: React Lessons from the Future

muskan thakur — Sun, 24 Nov 2024 17:07:06 +0000

Greetings from the future!

Yes, it’s me—well, you—a few loops down the timeline. Don’t freak out. I’ve mastered time travel (it involves quantum entanglement, a pinch of caffeine, and far too many sleepless nights debugging React hooks). I’m here to pass on some future wisdom to your present self. This isn’t some paradoxical attempt to rewrite our destiny but rather to save you from a lot of unnecessary facepalming.

So, grab your coffee (yes, the one you’re sipping while Googling “React useEffect keeps running infinitely”), and let’s embark on this temporal journey to level up your React game.

Lesson 1: Stop Fighting with State Management—Understand It

You’re about to waste weeks toggling between Redux, Context API, and that “useState-everywhere” approach that feels like duct-taping your app together. Here’s the deal:

Redux: It’s great when your app grows. But don’t shove it in for a to-do list app! Stick to local state or Context API until scaling demands something more robust.
Context API: Perfect for sharing small bits of global state, like themes or user data. But don’t treat it like Redux Lite—it can get messy fast with deeply nested components.
Recoil/Zustand: By 2024 (yeah, the future), simpler alternatives like these make state management feel like solving puzzles instead of defusing bombs. Keep an eye out for them.

Oh, and remember: state lifts up as often as Marty McFly messes up the timeline. Keep it high enough to share but low enough to avoid the dreaded "prop-drilling spaghetti."

Lesson 2: Hooks Are Your Friends—Use Them Wisely

Ah, hooks. Right now, they’re probably that shiny thing you want to use for everything but don’t fully understand. Let me save you the trial-and-error chaos:

useEffect: It’s not a lifecycle method replacement. Treat it like Schrödinger's box: it depends on dependencies. Over-relying on it will send you into infinite loops, but skipping dependencies will create ghost bugs. Always ask, what am I reacting to?
useMemo and useCallback: Don’t overuse them to optimize every render. Premature optimization is like trying to fix a time machine before it breaks. Use them sparingly for heavy calculations or stable callbacks.
Custom Hooks: When your code feels like déjà vu, extract it into a custom hook. It’s reusable, clean, and future-you will thank you.

Lesson 3: Component Architecture is Your Flux Capacitor

Remember that one project where you crammed everything into one giant App.js? Yeah, you do. Future you is shaking their head. Here’s what you should do:

Break Down Your Components: Keep them small and focused. One component = one responsibility.
Container and Presentational Components: Containers handle logic; presentationals handle UI. This split will keep your components neat, like a well-organized timeline.
Prop Drilling? Nah, Context or Props: Learn when to drill and when to share state contextually.

By mastering component design early, you’ll avoid building apps that feel like spaghetti timelines: tangled and impossible to debug.

Lesson 4: Ref Management – Your Tiny Superpower

Freshers like us often overlook refs. They seem niche, but trust me, they’ll save your bacon more than once. Here’s when to use them:

DOM Manipulation: Want to focus an input box or scroll to a specific section? useRef is your laser pointer in React’s virtual DOM world.
Persisting Values: Need to track a value without causing re-renders? Store it in a ref. Perfect for timers, intervals, or tracking previous state.
Avoiding Anti-Patterns: Don’t treat refs as a shortcut to update UI state. They’re not React’s state system. Think of refs as a sidekick, not the hero.

Lesson 5: What Freshers Always Get Wrong—Slow Down, Plan Better

This is where I really need to talk to you. You’re rushing. Building features without reading docs, copying snippets from Stack Overflow, and feeling victorious until something breaks.

Understand Before You Code: Don’t blindly copy code that “just works.” Take time to read the documentation and understand why it works.
Debugging is a Superpower: Learn how to use browser DevTools and React DevTools early. It’s not magic—it’s science.
Plan Your Features: Sketch out the component structure before diving in. Knowing what to build avoids rewriting half your code later.

Trust me: slowing down and planning will save you hours (and sanity) in the long run.

Final Words from Future You

React isn’t just a library—it’s a journey through the multiverse of UI development. You’ll hit roadblocks, question your life choices, and contemplate alternative careers. But trust me, every bug squashed, every component refactored, and every hook mastered is a step toward being the React wizard you’re destined to become.

And one last thing: don’t forget to take breaks. Coding while burnt out is like time traveling without coordinates—you’ll just end up lost.

See you in the future (or the next render cycle)!

With quantumly entangled regards,
Future You

The Truth About Prototypes in JavaScript: Flexibility vs. Performance

muskan thakur — Tue, 19 Nov 2024 12:20:44 +0000

Imagine this: Rick Sanchez, the smartest man in the multiverse, has just created a groundbreaking invention— the "Proto-Mind Machine." It allows him to pass down his memories, skills, and quirks to Morty through a prototype chain. Sounds wild, right? But how does this relate to JavaScript prototypes? Strap in, because we’re about to dive into the flexibility and performance trade-offs of JavaScript’s most fascinating concept.

What Are Prototypes?

In JavaScript, every object has a hidden property called [[Prototype]]. Think of it as a blueprint or ancestor that an object can inherit methods and properties from. It’s like how Morty inherits certain traits (though reluctantly) from Rick’s teachings—only in code, it’s more consistent.

// Rick creates the Proto-Mind blueprint
const protoMind = {
  geniusLevel: true,
  catchPhrase: "Wubba Lubba Dub-Dub!",
  inventGadget(gadget) {
    console.log(`Invented ${gadget}!`);
  },
};

// Morty inherits from Proto-Mind
const morty = Object.create(protoMind);

console.log(morty.geniusLevel); // true
morty.inventGadget("Portal Gun"); // Invented Portal Gun!

Here, morty doesn’t have the properties geniusLevel or inventGadget on its own. It borrows them from protoMind via the prototype chain. Just like Morty may sometimes act smarter because of Rick's influence, objects in JavaScript can "act" smarter by inheriting from their prototype.

Flexibility of Prototypes: The Multiverse of Options

The prototype chain makes JavaScript incredibly flexible. You can create objects that share behavior without needing to duplicate code, much like Rick replicating his brilliance across dimensions.

Dynamic Extensibility
Rick’s constant tinkering is a perfect analogy for JavaScript’s flexibility. You can modify prototypes on the fly, just as Rick alters his experiments mid-adventure.

protoMind.discoverUniverse = function (universe) {
  console.log(`Discovered Universe ${universe}!`);
};

// Morty can now discover universes too
morty.discoverUniverse("C-137"); // Discovered Universe C-137!

This dynamic behavior makes prototypes a powerful tool for rapid development and experimentation.

The Downside: Performance and Chaos

But here’s the twist: just like how Rick's chaotic experiments often backfire, JavaScript’s prototype chain can have performance drawbacks and unexpected behavior.

Performance Cost
When you access a property on an object, JavaScript traverses the prototype chain to find it. If the chain is too long or too complex, this can slow down execution, just like Rick's convoluted schemes sometimes leave Morty baffled.

// Long prototype chain
const rick = { smarts: true };
const dimensionRick = Object.create(rick);
const councilRick = Object.create(dimensionRick);

console.log(councilRick.smarts); // true (but requires multiple lookups)

Here, every property access involves a search up the chain. In performance-critical applications, this can become an issue.

Mutation Risks
If you change a prototype, it affects all objects inheriting from it. Imagine Rick uploading a corrupted memory into the Proto-Mind Machine—every Morty inherits the corruption.

protoMind.catchPhrase = "I'm Pickle Rick!";
console.log(morty.catchPhrase); // I'm Pickle Rick!

This shared nature of prototypes means changes can propagate in ways you don’t always expect, leading to bugs that are hard to trace.

Prototypes Are a Single Point of Truth

Here’s the mind-blowing part: prototypes create a "single point of truth" for shared behavior. This is efficient for memory usage since methods aren’t duplicated across instances. But it also means that changing the prototype changes the behavior for all instances—a double-edged sword.

Balancing Flexibility and Performance: Lessons from Rick and Morty

Keep Your Prototype Chain Manageable: Don’t create excessively deep prototype chains. Rick doesn’t need infinite Mortys; neither does your code.
Use Object.create for Clarity: When you need inheritance, prefer Object.create for cleaner and more explicit prototype setup.
Avoid Direct Prototype Mutation: Instead of modifying a prototype directly, consider encapsulating shared behavior in utility functions.
Measure Performance: If you’re building a performance-critical application (like a Galactic Federation tracker), profile your prototype-heavy code to ensure efficiency.

Conclusion: Prototypes, Multiverse, and Mastery

Understanding JavaScript prototypes is like navigating Rick’s multiverse—it’s flexible, full of possibilities, but not without its challenges. By mastering the trade-offs between flexibility and performance, you can wield the true power of prototypes, much like Rick’s Proto-Mind Machine.

In the end, remember Rick’s wisdom: “Don’t overthink it, Morty. Prototypes are tools, not rules.” Use them wisely, and you’ll unlock a multiverse of coding possibilities. Wubba Lubba Dub-Dub!

What’s your take? Have you ever encountered performance issues or quirky bugs with prototypes? Share your experience in the comments below!