DEV Community: Smile Gupta

😰 System design rounds used to scare me. Until I built a simple 2 2 quadrant to structure my thinking. I’ve finally written about it - with one example of Product Listing Page.

Smile Gupta — Mon, 05 May 2025 15:05:12 +0000

Smile Gupta

May 4 '25

Scared of System Design? Try This Tradeoff Quadrant

#webdev #systemdesign #javascript #frontend

Comments 11

7 min read

[Boost]

Smile Gupta — Mon, 05 May 2025 04:03:48 +0000

Smile Gupta

May 4 '25

Scared of System Design? Try This Tradeoff Quadrant

#webdev #systemdesign #javascript #frontend

Comments 11

7 min read

Scared of System Design? Try This Tradeoff Quadrant

Smile Gupta — Sun, 04 May 2025 17:49:57 +0000

I’m a frontend engineer.

And I still remember the first time someone asked me to “design a scalable system.”

I froze.

No docs. No clear starting point. Just a vague prompt and a blank whiteboard.

Eventually, I gave up and said, “I don’t think I can do this.”

It wasn’t that I didn’t know how to build things - I just didn’t know how to think in system design terms. What to prioritize. What to trade off. What even mattered.

Over time, through interviews, projects, and a lot of panic-Google moments, I started noticing a pattern in how I approached problems.

I’d always end up scribbling the same four kinds of thoughts: What we’re solving, How we’re building it, What can go wrong, and How it scales.

So I started putting them in a simple 2×2 quadrant.

Not a framework. Not a tool.

Just a small thing that helped me feel less stuck - especially during interviews.

This blog is me sharing that quadrant, and how you can use it too - whether you're prepping for interviews or just trying to design something with more clarity.

What is the Tradeoff Quadrant?

It’s just a 2×2 grid.

That’s it.

Whenever I’m designing something - a new feature, a reusable component, or even prepping for an interview - I draw a big “+” on paper or in my notes and start filling it in.

Each quadrant forces me to slow down and ask a different kind of question:

What are we solving? - What's the actual user problem? What’s the UX flow? What matters the most?

How will we build it? - What components do we need? Which rendering strategy makes sense - CSR, SSR, SSG? Is this a monolith or modular setup?

What can go wrong? - What if an API fails? What if data is missing? What happens on slow devices or bad networks?

How will it scale? - Will it handle more users? Can it support versioning or A/B testing later? Is it performance-optimized?

It’s not about filling it “perfectly” - it’s about making your thinking visible.

The best part? It works whether you're designing a whole page or just a single dropdown.

Let’s Apply This: Designing a Product Listing Page (PLP)

Imagine you're working at an e-commerce company and you've been asked to design the frontend system for a Product Listing Page (PLP) -like the ones you see on Amazon, Flipkart, or Myntra.

The page should:

Show a grid of products
Allow filtering by brand, size, price, etc.
Support sorting (price, popularity, newest first)
Handle pagination or infinite scroll
Be mobile- and desktop-friendly
Work well during high-traffic sale events
Support deep linking (URL reflects filters and sort)
Optionally inject ads or sponsored products between rows

Oh - and it should be fast, resilient, and easy to maintain over time.

Before jumping into components or API calls, let’s apply the Tradeoff Quadrant to understand the problem better.

Functional and Non-Functional Requirements

Once we’ve clarified the problem using the Tradeoff Quadrant, the next step is to define the requirements clearly - both functional and non-functional.

This helps prevent scope creep, sets expectations, and ensures you're designing for what actually matters.

I’ve also learned (sometimes the hard way 😅) that it’s important to think about what’s truly required to go to production. You can always add more later, but the goal of system design is to prioritize smartly, not just list every possible feature.

Functional Requirements

Must-haves for v1:

Display a grid of products with image, title, and price
Allow filtering by key fields like brand, price, and category
Support basic sort options (e.g., price low to high)
Enable pagination or infinite scroll
Reflect filter/sort state in the URL (deep linking)
Responsive layout that works on mobile and desktop

Nice-to-haves (can be added post-launch):

Sponsored ad injection between rows
Multi-select filters (e.g., select multiple brands)
Clear-all filters button
Breadcrumbs and category metadata
Prefetch next page data for smoother infinite scroll

Non-Functional Requirements

Production must-haves:

Debounced API calls to avoid unnecessary traffic
Graceful loading (skeletons or spinners)
Stable layout - avoid CLS (especially with ad slots)
Resilience to API failure (fallback UI)
SEO-ready with SSR for first PLP page
Keyboard + screen reader accessibility for filters and sort

Post-launch enhancements:

Telemetry for filter usage, scroll depth, and ad clicks
SWR/CDN caching for assets and filter config
Lazy image loading with IntersectionObserver
A/B testing for product card variants

Component Architecture for Product Listing Page

Now that we know what the PLP needs to do, let’s break it down into components.

The idea is to keep things:

Modular and reusable
Config-driven wherever possible
Scalable to accommodate features like ads, A/B tests, and SSR

Here’s a high-level breakdown of what that might look like:

<PLPPage />
├── <FilterSidebar />           ← Brand, size, price filters
│   └── <FilterGroup />
│       ├── <CheckboxFilter />
│       └── <RangeSliderFilter />
├── <SortBar />                 ← Sort options (dropdown or pills)
├── <ProductList />             ← Displays product + ad rows
│   └── <ProductRow />
│       ├── <ProductCard />
│       └── <SponsoredCard />   ← Conditionally rendered
├── <PaginationControls />      ← Or <InfiniteScrollLoader />
├── <SkeletonLoader />          ← Loading state for list
├── <EmptyState />              ← No results found
└── <TelemetryTracker />        ← Fires scroll, ad impressions, clicks

Each of these components plays a specific role in how the page functions and scales.

Let’s go through them quickly to understand how they fit into the bigger picture.

Component	Purpose
`<PLPPage />`	Top-level layout, parses URL params, triggers data fetch
`<FilterSidebar />`	Shows filter groups from config (brand, size, price, etc.)
`<FilterGroup />`	Renders a specific type of filter group (checkbox or range)
`<CheckboxFilter />`	Checkbox list filter (e.g., brand)
`<RangeSliderFilter />`	Price slider or size range selector
`<SortBar />`	Sort dropdown or pill selector (e.g., Popularity, Price)
`<ProductList />`	Renders the list of products and sponsored cards
`<ProductRow />`	Controls row layout (2/4 items)
`<ProductCard />`	Shows individual product info
`<SponsoredCard />`	Injected ad or sponsored placement
`<PaginationControls />`	Next/previous navigation or infinite scroll trigger
`<SkeletonLoader />`	Shimmer/skeletons for loading state
`<EmptyState />`	Shown when no products match the filters
`<TelemetryTracker />`	Tracks scrolls, filter usage, ad clicks, etc.

API Design for Product Listing Page

Now that the component architecture is in place, the next step is to design APIs that power the frontend cleanly.

Our API should:

Work across verticals (shoes, furniture, books, plants)
Support both products and sponsored content
Be config-driven to allow flexibility without hardcoding

Thought Process Behind the API Design

Instead of coupling the frontend logic to specific filters (like brand, size, material), the API should drive what filters to show via config.

This way, the filter sidebar becomes dynamic, and the same PLP can be used across different categories with little to no hardcoded logic.

We also want to inject ads or sponsored cards into the product list - so the response should include a mixed array of items, with each item tagged by its type.

To control where the sponsored card appears, we use a slotIndex - so the frontend can inject the card at that position without guesswork.

{
  "meta": {
    "total": 1870,
    "page": 3,
    "limit": 20,
    "hasMore": true
  },
  "filters": [
    {
      "type": "checkbox",
      "label": "Brand",
      "key": "brand",
      "options": ["Nike", "Puma", "Adidas"]
    },
    {
      "type": "range",
      "label": "Price",
      "key": "price",
      "min": 799,
      "max": 9999
    },
    {
      "type": "checkbox",
      "label": "Size",
      "key": "size",
      "options": ["6", "7", "8", "9", "10"]
    }
  ],
  "sortOptions": [
    { "label": "Popularity", "value": "popularity" },
    { "label": "Price: Low to High", "value": "price_asc" },
    { "label": "Newest First", "value": "newest" }
  ],
  "items": [
    {
      "type": "product",
      "slotIndex": 0,
      "data": {
        "id": "p123",
        "title": "Nike Air Max",
        "price": 3999,
        "image": "https://cdn/air-max.jpg",
        "rating": 4.5,
        "available": true,
        "badges": ["Best Seller"]
      }
    },
    {
      "type": "ad",
      "slotIndex": 1,
      "data": {
        "id": "ad789",
        "title": "Sponsored: Adidas Originals",
        "image": "https://cdn/ad.jpg",
        "ctaUrl": "https://yourstore.com/adidas-campaign",
        "trackingPixel": "https://track.adid.as/imp.png"
      }
    },
    ...
  ]
}

Why This API Design Works

Need	Solution in API
Configurable filters	filters[] object drives rendering
Category-specific logic	Backend sends only relevant filters
Sort options	Included as sortOptions[]
Ad/product mix	Unified items[] array with type
Placement control	slotIndex helps render at correct position
Frontend reusability	One PLP layout works across verticals

Performance Considerations

Once your API and component architecture are in place, the next big question is: “How will this perform in the real world?”

A Product Listing Page might work fine in local dev, but under real conditions - slow devices, 3G networks, high concurrency - things can fall apart quickly.

Here’s how I think about performance in PLPs:

Pagination and Debouncing

Always debounce filter and sort API calls to avoid flooding the network
For infinite scroll, make sure to throttle or lock pagination requests to prevent race conditions
Add a loading state between pages to give feedback and avoid double fetches

Virtualization and Lazy Loading

Use virtualization libraries like react-window or react-virtualized to render only visible products
Lazy-load images using IntersectionObserver so the initial page loads faster
Load ad creatives lazily too (especially 3rd party tracking pixels)

Skeletons and Perceived Performance

Show skeleton loaders instead of blank spaces during data fetch
Maintain layout stability with reserved space for ads to avoid layout shifts (CLS)
Preload next page data to make infinite scroll feel seamless

CDN, Caching, and SWR

Cache static filter config and sort options with SWR or localStorage
Use CDNs for product images and compress them using WebP or AVIF
Apply stale-while-revalidate caching strategy to keep PLP snappy without stale content

Telemetry and Monitoring

Track API response times, scroll depth, filter interaction, and ad clicks
Set up frontend alerts if API failure rate exceeds a threshold
Use these metrics to guide A/B testing and UX decisions

What I’d Say in an Interview

“In PLPs, performance is not just about speed - it’s about perception. Skeletons, lazy loading, and virtualization make a huge difference. I’d also make sure filter configs are cached, ads don’t block the main thread, and all API calls are debounced.”

Final Thoughts

If system design has ever made you freeze up, just know - you’re not alone.

I made this quadrant because I needed something simple to help me get unstuck.

Whether you’re preparing for an interview or solving a problem at work, I hope this gives you a way to slow down, ask better questions, and design with confidence.

And if this helped, let me know - or share your own version of the quadrant. I’d love to see it. 🙂

Do you remember the last time something broke at work and you were right in the middle of it? Mine started with a “safe” version bump and ended with checkout disappearing in prod 😬 Wrote about my first prod outage - what went wrong, what i learned.

Smile Gupta — Mon, 31 Mar 2025 13:45:20 +0000

Smile Gupta

Mar 31 '25

I Thought It Was a Safe Deploy… Until Checkout Disappeared

#webdev #programming #career #javascript

Comments 4

6 min read

I Thought It Was a Safe Deploy… Until Checkout Disappeared

Smile Gupta — Mon, 31 Mar 2025 13:12:07 +0000

It started like any other normal deploy.

A version bump. Nothing fancy. The kind of change that slips into prod without fanfare.

We had tests. Dev looked good. It was reviewed. Merged. ✅

And for a while… everything was fine.

Then the PagerDuty alert went off.
Then Slack lit up with:

“Checkout’s not loading.”
“The screen is blank.”
“Apple Pay’s broken.”

And that’s when my heart sank.
Because this wasn’t just a bug.
This was the entire payment flow going down.

What made it worse?
It was my first real production outage.

I’d read about outages before. I’d seen postmortems.

But nothing prepares you for what it feels like when your code takes down checkout.

When you're on an incident bridge, adrenaline kicking in, trying to act calm while your mind is racing.

If you’ve ever worked on a checkout team, you know how high the stakes are.

If you haven’t-trust me, this is the kind of breakage that makes your stomach drop.

This isn’t a deep technical write-up. It’s a story.

About what happened, what I learned, and what I wish I knew going in.

So when your moment comes (and it will), maybe you’ll feel a little more ready than I did.

🧨 Part 1: What Changed (And What Went Wrong)

To the readers who don’t know me personally or know what I do to pay my bills — I work on the web side of payments, maintaining internal libraries that power checkout flows across different products.

It’s a space that lives quietly in the background when everything’s working… and turns into absolute chaos when something breaks.

Recently, we had to update the Apple Pay SDK.

The version we were using had been deprecated by the Apple team, and the new one introduced a few changes in the API contract—mostly around how inputs were passed during initialisation.

We made the necessary updates, tested everything on dev, and it all looked solid. ✅
So we merged it and shipped it.

A while later, we got alerted about a spike in Apple Pay errors.

At first, it felt like a small fire.

But as we started digging in, it quickly escalated.

We discovered that the updated SDK relied on a function that wasn’t supported in certain older browsers. That resulted in a runtime error early in the flow-so early that it completely broke the entire checkout experience.

No Apple Pay.

No other payment methods.

Just a blank screen.

⚠️ First Things First - Don’t Start with Debugging

Before we go into what we found, here’s one thing I learned that I’ll never forget:

When you're facing a production outage, your first instinct shouldn’t be to start debugging.

That’s the mistake I almost made.
Because when your code is involved, your brain goes:

“Okay, where’s the bug? What broke? Let’s fix it.”

But here’s the thing: debugging takes time.

And while you’re digging through logs and testing theories, real users are getting blocked.

Revenue is dropping. The company is losing money. And most importantly, people are having a bad experience.

Unless you know the fix and you're confident it's safe to ship fast, the best move is this:

👉 Revert the commit. Redeploy. Stabilize.

It might not feel heroic, but trust me - it's the most responsible thing you can do.

The goal isn’t to debug under pressure. The goal is to stop the bleeding.

And then, when the incident is over, you can figure out what actually went wrong.

And that’s exactly what we did.

We rolled back the commit.

The blank screen went away. Checkout came back. Users could pay again.

The incident bridge went quiet.

PagerDuty stopped yelling.

But the work wasn’t over.

Now it was on us to figure out exactly what broke and why.

🛠️ Part 2: The Debug Spiral - What We Found

Once things were stable again, it was time to figure out what had actually happened.

The incident bridge was done. The pressure had dropped.

But the ownership was still on us to make sure we knew exactly why checkout had broken, and how to prevent it from ever happening again.

So we started going through logs, testing browsers, and trying to reproduce the issue in a controlled way.

At first, it was confusing.

There was no visible crash.

No red banners. No clean stack trace on screen. Just… silence.

The kind that’s somehow more unsettling than an obvious error.

Eventually, we spotted it: A runtime error coming from deep inside the updated Apple Pay SDK.

It was trying to use a method that wasn’t supported in some older browser environments.

That’s when it clicked:

Of course it was happening on Safari.

Apple Pay is only supported on Safari so if something in the SDK was going to fail, that’s exactly where it would show up.

And that’s what was happening here.

In certain versions of Safari, this one method wasn’t available.
And since the SDK tried to use it during initialization, it caused a hard crash.

Not just for Apple Pay.

But for everything.

Because the failure happened at the top level of our checkout bootup, no other payment methods loaded either.

No UI. No error message. Just a blank screen.

The kind of bug that slips past on dev.
And punches you right in prod.

🧠 Part 3: It's Not Just About the Fix - It's About Ownership

The bug was found. The rollback was done. Users could pay again.
But I knew my job wasn’t over.

Because being a good engineer doesn’t stop at unblocking users.

It starts when you step back and ask:

What did this break mean for the user?
How much revenue did we potentially lose?
What did this outage cost the business?
Could this have been caught earlier?
Will it happen again?

We’re not just here to respond to alerts and patch code like we’re on an assembly line.

We’re not coders you can prompt like ChatGPT and expect the problem to disappear.

We’re here to think deeply, own outcomes, and prevent future damage.

So I started writing.

I documented everything:

What we changed
Why we changed it
What failed (and where)
How it slipped past QA
What we missed in our monitoring
And what browser/version combos were affected

Not because someone told me to, but because future-me (or future teammates) might run into something similar and I want them to have answers faster than I did.

💡 What This Taught Me - and What I Want to Push For

This outage didn’t just teach me what went wrong.

It made me pause and ask: what would I do differently if this happened again?

So I started jotting down ideas.

Not all of them are done yet. Some are in progress.

But they’re now on my radar and they weren’t before this incident.

Here’s what I’m exploring post-outage:

🧪 Introducing browser-specific test cases, especially for critical SDK integrations
🛡️ Adding guard clauses around third-party SDKs to prevent one failure from taking everything down
📉 Revisiting alert thresholds and adding more granular monitors (especially for visual regressions and blank states)
📊 Surfacing “what changed in this release” summaries to make incident triage faster
📚 Starting a habit of writing lightweight incident summaries for internal sharing and future reference

These aren’t silver bullets.

But they’re the kinds of things I now know matter and they’re on my roadmap moving forward.

🧘‍♀️ Part 4: Wrapping It All Up

If you’ve made it this far thank you.

This wasn’t the easiest thing to write, but I wanted to put it out there because… no one tells you what your first production fire feels like.

It’s messy.

It’s stressful.

And sometimes, yes it’s your code.

But you learn.

You learn what it really means to take ownership.

You learn to zoom out and think beyond “what broke” and start asking “who did this impact?”

You learn that being a good engineer isn’t about writing perfect code - It’s about how you show up when things aren’t perfect.

I’m still learning. But one thing’s for sure: this incident taught me more than weeks of “normal” engineering ever could.

✅ A Checklist for When (Not If) It Happens to You

Here’s a simple list I wish I had in front of me when it all went down:

🔄 Don’t start debugging immediately - if the issue is real and users are impacted, revert first, then investigate
📣 Communicate early - even just “Looking into it” goes a long way in incident channels
🧪 Try reproducing the issue in controlled environments (same browser, device, etc.)
🔍 Check logs, network calls, error boundaries - don’t assume it’ll crash loudly
📉 Review your monitoring thresholds - are they tuned to catch subtle failures early?
📚 Document what happened, in plain language - not just for your team, but for future you
🧠 Think about business impact - how many users were affected, and for how long?
✍️ If you find patterns or takeaways, write them down - they’re gold in the next incident

In the end I can just say this, breaking prod might not be a badge of honour - but surviving it? Definitely is.

If this story helped you - or reminded you of your own - you can always reach out.

Would love to connect with others who’ve been through the fire. 🔥

📍Twitter / X: smileguptaaa

7 hard-earned frontend lessons from real-world mistakes, rewrites, and “why did I do that?” moments 😅

Smile Gupta — Sun, 23 Mar 2025 12:00:29 +0000

7 Lessons That Would’ve Saved Me Years as a Frontend Engineer

Smile Gupta ・ Mar 22

#webdev #javascript #systemdesign #frontend

7 Lessons That Would’ve Saved Me Years as a Frontend Engineer

Smile Gupta — Sat, 22 Mar 2025 11:40:28 +0000

A few years ago, if you had asked me what system design was, I probably would’ve said something like "backend stuff, right?" 😅

I was great at building UIs, designing components, and getting things pixel-perfect.

But when it came to structuring large-scale frontend applications, making trade-offs, or just knowing how to communicate design decisions, I felt... completely lost.

And the thing is - I’m not alone.

System design can feel like a black-box, especially for frontend engineers.

Most of us aren’t taught how to think about it. We’re just expected to magically know.

I messed up projects. I over-engineered where I shouldn’t have.

And sometimes, I just froze - because I didn’t know where to start.

I realised I couldn’t keep winging it.

I started asking better questions, learning from smarter folks, observing how teams made decisions - and most importantly, writing it all down.

Here are 7 things I wish I had known earlier - lessons that would’ve made me a better engineer, faster, and definitely saved me a few headaches.

1. System Design Isn’t Just for Backend Engineers

It took me way too long to realize that frontend systems need design too.

I used to think system design was mostly about backend things - like databases, queues, and server scaling. But on the frontend, we make equally important decisions every day.

You're not just placing buttons on a page. You're deciding:

How the page loads
When data is fetched
What happens if something fails
How to keep things fast and smooth for the user

Let me give you a few quick examples:

A travel homepage (like Airbnb):
You want it to load fast, feel personal, and also be SEO-friendly.
Should you render it on the client, server, or use static generation? Each has pros and cons. Picking one means thinking about performance, infra, and user experience. That’s system design.
An internal dashboard: No SEO needed, but tons of data and filters.
You might use client-side rendering, debounce search input, and show skeleton UIs while loading. All small things - but together, they make or break the experience.
A blog or marketing site: Rarely changing content? Great candidate for static generation + CDN.
That’s a conscious design call too.

These are everyday decisions. But when you step back and look at them, they're not just "frontend choices" - they're system choices.

And I wish I had realized that sooner.

2. Start with Questions, Not Solutions

One of the biggest mistakes I made early on was jumping straight into diagrams.

The moment someone asked me to design a system, I’d start drawing boxes, talking about React, maybe throwing in a Redux for good measure 😅

But I had no idea why I was making those choices.

Over time, I learned that the best engineers don’t start with architecture.

They start with questions.
They pause. They listen.
They try to understand the problem before jumping into a solution.

Here are some of the questions I now ask - whether I’m in an interview or building something at work:

Problem & Context

What is the core goal of this system?
Who are the users?
What’s the first thing they need to see?
Are there different user roles (admin, guest, etc.)?

Scope & Constraints

What’s in scope? What’s explicitly out of scope?
Are there time constraints, team size limits, or tech restrictions?
Should this work on mobile, desktop, tablets?

Performance & Experience

Do we care about SEO? (i.e. should we consider SSR or SSG?)
What kind of performance is expected? (First load, interactions)
Is this expected to work offline or in low-network conditions?

Edge Cases & Reliability

What happens when the API fails?
What should the user see during loading? Empty state? Errors?
Do different users see different versions of the UI?

Asking these questions has changed everything for me.

Now, instead of throwing tech at the wall and hoping it sticks, I build systems that are designed with purpose.

Because when you ask better questions, you make better decisions.

3. Performance Isn’t Just an Afterthought

There was a time when I’d build an entire app, make sure all the features were working, and only then start thinking about performance.

Unsurprisingly, it often led to painful fixes, unnecessary rewrites, and slow experiences that frustrated users and me.

I used to treat performance like a finishing touch. But eventually, I realized that performance isn’t something you sprinkle on at the end. It’s something you design for from the beginning.

One mindset shift that helped me was setting a clear, simple performance goal at the start of a project. For example, just deciding early that "the first screen should load in under 2 seconds on 4G" shaped every technical choice I made after that. It wasn’t about chasing perfection or Lighthouse scores, it was about building something usable, fast, and intentional.

Performance is not about one magical trick. It’s about small, thoughtful choices that add up. Here are some of the things I now consider early in the design process:

Over time, I built a habit of thinking about performance as part of system design. Here are some of the things I now consider early:

I lazy-load non-critical components, so the user isn’t blocked waiting for everything at once.
I split large JavaScript bundles, so the browser doesn’t stall parsing huge files.
I preload above-the-fold assets to improve the time-to-first meaningful paint.
I compress images, and prefer modern formats like WebP to reduce size without losing quality.
I defer loading content that’s below the fold, especially on mobile.
I use skeleton loaders instead of spinners to create a smoother perceived experience.
I cache API responses where possible to avoid unnecessary network calls.
I virtualize long lists or large tables, especially in dashboards and internal tools.
I debounce or throttle expensive interactions, like live search or input-heavy forms.
I avoid unnecessary re-renders in React using tools like React.memo or useCallback.
I add resource hints like dns-prefetch, preconnect, and preload for critical resources.

You don’t need to implement all of these in every project. But being aware of them early lets you make smarter, more intentional design decisions.

These days, performance is no longer something I "get to later". It’s part of how I think from day one.

4. Trade-Offs Matter More Than "Right Answers"

When I started learning system design, I thought the goal was to find the best solution - the one with the cleanest code, the best architecture, and zero compromises.

But over time, I learned something more valuable:
There’s rarely one "right" answer. What matters more is understanding and explaining the trade - offs.

As frontend engineers, we make these kinds of decisions all the time:
For example, I once had to decide between using client-side rendering (CSR) or integrating server-side rendering (SSR) for a new product detail page.

CSR would be simpler and fit right into our existing setup, but the team wanted better SEO for product discovery.
SSR would improve crawlability, but it added complexity we hadn’t dealt with before.

We eventually decided to go with CSR for the initial release, and planned to introduce SSR for high-impact pages later. That wasn't a perfect solution - but it let us move faster while keeping future needs in mind.

Another time, I worked on a filter-heavy table for an internal dashboard.
The backend APIs were flexible, so we had two options:

Fetch all data at once and filter it on the client, or
Fetch filtered results on demand with every interaction.

We chose client-side filtering for simplicity and speed at small scale, knowing that we’d eventually have to switch if the data grew too large.

Neither solution was perfect. But both worked - because we made the decision consciously.

That’s the real skill in frontend system design: Not picking the "best" tech, but knowing what you’re trading off and being able to say, "Here’s what I’m choosing, and here’s why it makes sense for now."

In a nutshell, IMO Design isn’t about being right. It’s about being thoughtful.

5. Design for the Team, Not Just Yourself

There was a phase where I really loved writing "clever" code.
Reusable hooks, abstracted components, custom configurations, dynamic props - everything looked clean and powerful to me.

But I slowly started noticing something.

Other folks on the team - especially newer devs or folks who hadn’t worked on that part of the codebase - struggled to make sense of what I’d built.

What I thought was "Clean and DRY" was actually "hard to follow and scary to touch."

That’s when I realised: good system design isn’t about showing off. It’s about building something others can work with.

Now, when I’m designing a component, flow, or data structure, I ask myself:

Will this be easy to onboard into?
Can someone new understand this in 10-15 minutes?
If I’m on leave, will someone else be able to debug this?

I’ve also started embracing boring, obvious solutions.

Things like:

Writing components that are slightly repetitive but readable
Adding in-line comments for future context
Avoiding over-abstraction, even if the logic looks a bit duplicated
Creating clear folders and naming things with intent, not cleverness

It’s not about dumbing things down. It’s about being kind to your team, to your future self, and to anyone else who might touch your system months later.

Because the best frontend systems?

They’re not the ones that look smartest.

They’re the ones that let everyone build confidently - without fear of breaking things.

6. State Management is a Design Problem

For the longest time, I treated state as "just another implementation detail."
If something needed to remember its value, I’d chuck it into useState, or maybe Context if it was "global."

No real plan. Just vibes.

But over time, I started noticing how often state caused bugs, confusion, and painful refactors.

And I realised: where state lives, how it flows, who owns it - that’s not just a coding problem.

That’s a system design problem.

I’ve seen components break because the state was shared across places that shouldn’t talk to each other.

I’ve seen teams struggle to manage loading flags, local UI state, backend data, and user preferences - all tangled together in one giant store.

Here’s what I’ve learned: The best systems have a clear state plan before a single line of code is written.

Now when I approach state, I ask:

What kind of state is this? (UI state? server state? app-level config?)
Where should it live? (local component? context? server cache like React Query?)
Who should own it? (can it be co-located or does it need to be lifted?)
Does it need to persist between routes or sessions?

Sometimes, the answer is simple - like using useState for a toggle.

Other times, it’s better to reach for tools like Zustand, Redux Toolkit, or React Query if the state is shared or tied to API responses.

And sometimes… I don’t need a library at all.

Just a clear, intentional structure.

The goal isn’t to "use the best tool."

The goal is to design a flow where the right data lives in the right place - and the team can reason about it without going through five layers of context.

Once I started thinking about state like part of the system architecture, not just component logic, everything became smoother: fewer bugs, easier debugging, and way less stress when the app grew.

7. The Real Skill is Communication

When I first heard the phrase "system design," I thought it was all about architecture diagrams, performance tricks, and naming patterns I hadn’t memorised yet.

But the more I grew as an engineer, the more I saw that the people who stood out weren’t always the ones with the fanciest answers - they were the ones who could communicate their thinking clearly.

In interviews, in design reviews, or even just whiteboarding with teammate, being able to say:

"Here are the options I considered…"
"I chose this because of X, even though it comes with Y."
"If the scale grows, we can evolve the system like this…"

That kind of communication builds trust.

It shows that you’re not just throwing tech around - you’re thinking, planning, and designing on purpose.

I’ve had rounds where I didn’t get everything right.

I didn’t pick the exact pattern they were expecting.

But I got the role - because I asked good questions, explained my reasoning, and stayed calm under ambiguity.

And honestly? That mirrors the real world.

You’ll never have all the context.

You’ll rarely be 100% certain.

But if you can think out loud, involve others in your process, and show that you're weighing decisions thoughtfully - that’s what system design is actually about.

In the end, it’s not about being perfect.

It’s about being clear, collaborative, and adaptable.

And that’s a skill worth practicing.

What happened after I learned all this?

Once I started looking at frontend system design this way, everything shifted.

I stopped jumping into code without a plan.

I started asking better questions.

I began thinking more like a builder - with structure, clarity, and intention.

And over time, I built a system for myself - a mental checklist I could follow.

It helped me in interviews.
It helped me in real projects.

Not because I have all the answers.

But because I wish someone had handed me something like this when I was struggling to make sense of it all.

That’s when I decided to turn it into a handbook.

📘 Frontend System Design: The Guide I Wish I Had - a practical guide for engineers who want to build better systems, and think beyond just writing code.

It covers everything we talked about here and more - how to approach problems, structure your thinking, handle trade-offs, and actually enjoy system design.

👉 Grab your copy here

Thanks for reading 💙

If you’re someone trying to level up your frontend skills - especially around system design - I hope this helped.

And if you’re preparing for an interview right now - you got this.