G.Jonathan

𝗗𝗮𝘆 𝟮𝟬 𝗼𝗳 #𝟭𝟬𝟬𝗗𝗮𝘆𝘀𝗢𝗳𝗦𝘆𝘀𝘁𝗲𝗺𝗗𝗲𝘀𝗶𝗴𝗻 — 𝗛𝗮𝘀𝗵 𝗜𝗻𝗱𝗲𝘅𝗲𝘀 𝘃𝘀 𝗕-𝗧𝗿𝗲𝗲𝘀 Yesterday, we talked about indexing and why databases need shortcuts to stay fast. Today, the real question is: what kind of shortcut are you using? Not all indexes are created equal. A 𝗵𝗮𝘀𝗵 𝗶𝗻𝗱𝗲𝘅 works by taking a key, running it through a hash function, and jumping straight to the location of the data. 𝗪𝗵𝗲𝗻 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀, 𝗶𝘁’𝘀 𝗶𝗻𝗰𝗿𝗲𝗱𝗶𝗯𝗹𝘆 𝗳𝗮𝘀𝘁. Exact lookups feel almost instant. But there’s a catch. Hash indexes don’t understand order. They can’t efficiently handle ranges, sorting, or queries like “greater than” or “less than.” This is where B-Trees come in. A 𝗕-𝗧𝗿𝗲𝗲 keeps data sorted at all times. Instead of jumping blindly, it navigates through a structured tree that narrows down results step by step. Reads are slightly slower than hash lookups, but the flexibility is unmatched. Range queries, sorting, and ordered scans all become natural. 𝗧𝗵𝗶𝗻𝗸 𝗼𝗳 𝗮 𝗿𝗲𝘀𝘁𝗮𝘂𝗿𝗮𝗻𝘁 𝗮𝗴𝗮𝗶𝗻. A hash index is like assigning seats purely by a reservation code. If you know the exact code, you’re seated instantly. But if someone asks for a table near the window or wants to see all available tables for four, the system breaks down. A B-Tree is like arranging tables by size and location. It might take a moment to walk through the dining area, but you can easily handle preferences, ranges, and changes. This is why most relational databases default to B-Trees. They trade a little raw speed for predictability and flexibility at scale. Good system design isn’t about choosing the fastest option. It’s about choosing the option that fails gracefully as requirements grow.

Most people are not stopped by lack of talent or intelligence. They are stopped by impatience. Growth, in its raw form, is repetitive and often uneventful.

𝗗𝗮𝘆 𝟮𝟭 𝗼𝗳 #𝟭𝟬𝟬𝗗𝗮𝘆𝘀𝗢𝗳𝗦𝘆𝘀𝘁𝗲𝗺𝗗𝗲𝘀𝗶𝗴𝗻 𝗟𝗦𝗠 𝗧𝗿𝗲𝗲𝘀 𝗘𝘅𝗽𝗹𝗮𝗶𝗻𝗲𝗱 So far in this series, we’ve talked about indexes, 𝗵𝗮𝘀𝗵 𝗶𝗻𝗱𝗲𝘅𝗲𝘀, and 𝗕-𝗧𝗿𝗲𝗲𝘀. Most of those structures are built to make reads fast. But not every system is read-heavy. 𝗦𝗼𝗺𝗲 𝘀𝘆𝘀𝘁𝗲𝗺𝘀 𝗮𝗿𝗲 𝗱𝗲𝘀𝗶𝗴𝗻𝗲𝗱 𝘁𝗼 𝗮𝗯𝘀𝗼𝗿𝗯 𝗺𝗮𝘀𝘀𝗶𝘃𝗲 𝗮𝗺𝗼𝘂𝗻𝘁𝘀 𝗼𝗳 𝗱𝗮𝘁𝗮 𝗰𝗼𝗻𝘁𝗶𝗻𝘂𝗼𝘂𝘀𝗹𝘆. For those systems, write performance matters more than anything else. That’s where LSM Trees come in. 𝗔𝗻 𝗟𝗦𝗠 𝗧𝗿𝗲𝗲 𝗮𝘃𝗼𝗶𝗱𝘀 𝗿𝗮𝗻𝗱𝗼𝗺 𝗱𝗶𝘀𝗸 𝘄𝗿𝗶𝘁𝗲𝘀. Instead of updating data in place, new writes are stored in memory first. When memory fills up, the data is flushed to disk sequentially into immutable, sorted files called SSTables. SSTables are never modified after they’re written. This allows the database to turn many small random writes into large, efficient sequential writes, which disks handle much better at scale. Reads become more complex because data may exist in multiple SSTables. To keep reads fast, systems use optimizations like bloom filters to quickly check whether a key exists, sparse indexes to jump to the right block, and caching to avoid disk access when possible. Updates and deletes don’t remove data immediately. Instead, the system writes tombstones, which act as markers saying a value is no longer valid. During background compaction, old data and tombstones are merged and cleaned up. A restaurant analogy helps. During a rush, dirty plates are stacked at the counter instead of being taken inside one by one. Once the stack is full, plates are taken inside and washed in batches. The kitchen stays efficient even under pressure. LSM Trees make the same tradeoff. Writes are fast and predictable. Reads are more involved. Background compaction keeps everything under control. This is why systems like Cassandra, HBase, and RocksDB are built around LSM Trees. my linkedin has the complete series so far

Being working on creating a very interesting space for my circle of friends inncircle.org Amazing Its finally hereeee

𝗗𝗮𝘆 𝟮𝟮 𝗼𝗳 #𝟭𝟬𝟬𝗗𝗮𝘆𝘀𝗢𝗳𝗦𝘆𝘀𝘁𝗲𝗺𝗗𝗲𝘀𝗶𝗴𝗻 — 𝗥𝗲𝗮𝗱-𝗛𝗲𝗮𝘃𝘆 𝘃𝘀 𝗪𝗿𝗶𝘁𝗲-𝗛𝗲𝗮𝘃𝘆 𝗦𝘆𝘀𝘁𝗲𝗺𝘀 System design rarely fails because of bad tools. It fails because of bad assumptions. Every system leans toward a dominant workload. It either reads data far more often than it writes it, or it writes data far more often than it reads it. 𝗥𝗲𝗮𝗱-𝗵𝗲𝗮𝘃𝘆 𝘀𝘆𝘀𝘁𝗲𝗺𝘀 𝘀𝗲𝗿𝘃𝗲 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝗱𝗮𝘁𝗮 𝗿𝗲𝗽𝗲𝗮𝘁𝗲𝗱𝗹𝘆. Think user profiles, product catalogs, and feeds. 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲𝘀 𝗹𝗶𝗸𝗲 𝗣𝗼𝘀𝘁𝗴𝗿𝗲𝗦𝗤𝗟, 𝗠𝘆𝗦𝗤𝗟, 𝗮𝗻𝗱 𝗘𝗹𝗮𝘀𝘁𝗶𝗰𝘀𝗲𝗮𝗿𝗰𝗵 fit naturally here because they are optimized for fast queries and indexing. 𝗪𝗿𝗶𝘁𝗲-𝗵𝗲𝗮𝘃𝘆 𝘀𝘆𝘀𝘁𝗲𝗺𝘀 𝗶𝗻𝗴𝗲𝘀𝘁 𝗱𝗮𝘁𝗮 𝗰𝗼𝗻𝘁𝗶𝗻𝘂𝗼𝘂𝘀𝗹𝘆. Logs, metrics, and events don’t pause. D𝗮𝘁𝗮𝗯𝗮𝘀𝗲𝘀 𝗹𝗶𝗸𝗲 𝗖𝗮𝘀𝘀𝗮𝗻𝗱𝗿𝗮, 𝗛𝗕𝗮𝘀𝗲, 𝗗𝘆𝗻𝗮𝗺𝗼𝗗𝗕, 𝗮𝗻𝗱 𝗥𝗼𝗰𝗸𝘀𝗗𝗕 are built for this reality, prioritizing write throughput and background processing. A restaurant analogy helps. Fine dining optimizes for serving guests quickly. Buffets optimize for volume and flow in the kitchen. System design starts when you stop asking “what database should I use?” and start asking “what happens more often — reads or writes?” More depth and visuals are in today’s LinkedIn post. (linkedin.com/posts/gobiuwevb…)

Felt really goood when a friend posted this! Today was really goooooooood.

𝗗𝗮𝘆 𝟳: 𝗦𝘁𝗮𝘁𝗲𝗹𝗲𝘀𝘀 𝘃𝘀 𝗦𝘁𝗮𝘁𝗲𝗳𝘂𝗹 𝗦𝘆𝘀𝘁𝗲𝗺𝘀 #𝟭𝟬𝟬𝗗𝗮𝘆𝘀𝗢𝗳𝗦𝘆𝘀𝘁𝗲𝗺𝗗𝗲𝘀𝗶𝗴𝗻 Its been one week of talking about design systems and constantly designing my slides with Canva that are fully posted on Linkedin! Loving how this is going. Yesterday, we talked about horizontal scaling and how adding more machines helps systems grow. Today, let’s talk about something that becomes critical once you do that 𝘀𝘁𝗮𝘁𝗲𝗹𝗲𝘀𝘀 𝘃𝘀 𝘀𝘁𝗮𝘁𝗲𝗳𝘂𝗹 𝘀𝘆𝘀𝘁𝗲𝗺𝘀. Before we define them, first understand this state is any information a system needs to remember between requests. So what’s the difference? A stateful system remembers information about a user or request. If a user sends another request, it must go back to the same server that remembers them. A stateless system does not remember anything. Every request contains all the information needed and can be handled by any server. Think of it like a restaurant: In a stateful restaurant, a waiter remembers your face, your table, and your order. If you talk to a different waiter, they’re confused. That waiter is the server. Your memory lives with them. In a stateless restaurant, every waiter writes orders on a shared board. Any waiter can pick it up and continue serving you. That shared board is external storage. This is why stateless systems scale better horizontally. Requests can go anywhere. Failures don’t break the flow. Stateful systems still matter, but they need more coordination. Tomorrow, we’ll talk about where state actually lives in scalable systems.