<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Preksha Barjatya]]></title><description><![CDATA[Preksha Barjatya]]></description><link>https://prekshabarjatya.hashnode.dev</link><generator>RSS for Node</generator><lastBuildDate>Sat, 07 Nov 2026 14:16:14 GMT</lastBuildDate><atom:link href="https://prekshabarjatya.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[System Design for Beginners: Stop Coding First]]></title><description><![CDATA[Learn what HLD and LLD mean, how to define requirements, and how to make trade-offs with simple real-life examples.]]></description><link>https://prekshabarjatya.hashnode.dev/system-design-for-beginners-stop-coding-first</link><guid isPermaLink="true">https://prekshabarjatya.hashnode.dev/system-design-for-beginners-stop-coding-first</guid><category><![CDATA[System Design]]></category><category><![CDATA[software architecture]]></category><category><![CDATA[beginnersguide]]></category><dc:creator><![CDATA[Preksha barjatya]]></dc:creator><pubDate>Fri, 06 Nov 2026 04:00:17 GMT</pubDate><content:encoded><![CDATA[<p>Picture a ticket-booking site that works perfectly for 10 testers. Then sale day arrives, 50,000 people click "Book" at 10 AM, and everything freezes. Nothing was wrong with the code. What was missing was a design: someone deciding in advance how the system should behave under pressure. That skill is <strong>System Design</strong>, and it comes down to making smart trade-offs.</p>
<h2>Plan the wedding before you cook the menu</h2>
<p>Think of organising a big wedding. First you decide the venue, the caterer, how guests flow from parking to the stage, and what happens if it rains. That is <strong>High-Level Design (HLD)</strong>: the big picture and the structure.</p>
<p>Only then do you sort out the details: the exact menu, how much salt goes in each dish, who sits at which table. That is <strong>Low-Level Design (LLD)</strong>. A great cook who has never planned the event is still just a cook. The planner is the architect.</p>
<img src="https://cdn.hashnode.com/uploads/covers/6aed4d698024c695387b4df6/614f6ba7-fd67-44e8-b0d0-d7f653335da5.png" alt="" style="display:block;margin:0 auto" />

<h2>Ask "What?" before you draw</h2>
<p>Suppose someone says, "Design a food delivery app." Resist the urge to draw boxes. Define the requirements first.</p>
<ul>
<li><strong>Functional (the What):</strong> Can I browse restaurants? Place an order? Track my rider?</li>
<li><strong>Non-functional (the How):</strong> Does the order confirm within 2 seconds? If the payment fails, is my order lost or safely retried? Does the app survive the Friday 9 PM dinner rush?</li>
</ul>
<p>The second list is what separates a weekend project from a product people trust.</p>
<h2>The 9 tuning knobs</h2>
<p>Every system is shaped by nine qualities: scalability, availability, reliability, performance, consistency, durability, security, cost and maintainability. Think of a phone camera. More megapixels means bigger files and slower sharing. Better night mode means a higher price. You cannot max out every knob at once.</p>
<img src="https://cdn.hashnode.com/uploads/covers/6aed4d698024c695387b4df6/2aed5f00-9f8b-43a4-b85a-30a309841d69.png" alt="" style="display:block;margin:0 auto" />

<h2>There is no "best" answer</h2>
<p>When you buy a phone, you pick between great battery, slim design and a low price, and you will not get all three. Software forces the same choice.</p>
<p>Take railway seat booking. Two people tap the last seat at the same moment, and exactly one must get it. That needs strict <strong>consistency</strong>, even if it makes the page a little slower. Now take the "12 people are looking at this" banner on a shopping site. If it shows 12 when the real number is 14, nobody is harmed, so the site picks <strong>speed and availability</strong> and lets the number catch up a moment later.</p>
<img src="https://cdn.hashnode.com/uploads/covers/6aed4d698024c695387b4df6/dd87b575-44dd-458d-b756-245a0493c745.png" alt="" style="display:block;margin:0 auto" />

<h2>The takeaway</h2>
<p>An architect does not hunt for the right answer. They hunt for the least bad trade-off for the problem in front of them, and they can explain why.</p>
]]></content:encoded></item></channel></rss>