Mastering System Design: Core Elements, Steps, and Performance Strategies

What Is System Design

System design is the process of designing system elements such as architecture, modules, components, their interfaces, and data structures. The goal is to provide detailed information that aligns with the architectural entities defined in system models and views.

System Elements

Architecture – Conceptual model defining system structure, behavior, and views, often illustrated with flowcharts.

Module – Component that handles a specific task; modules combine to form the system.

Component – Provides a specific function or a set of related functions; composed of modules.

Interface – Shared boundary through which system components exchange information.

Data – Management of information and data flow.

Main Tasks Executed During System Design

First list the primary tasks involved in the given system design problem, focusing on front‑end product functionality.

1) Understand What It Is

Identify the problem, confirm requirements with stakeholders, and ensure correct interpretation of the problem statement.

What kind of product is being created?

Are we discussing the same service?

2) Determine the Appropriate Scope

After understanding the problem, decide the boundaries. Time is limited (typically 45 minutes to 1 hour), so prioritize the most confident parts and defer the rest.

Scope cannot cover a perfect service; focus on core features that can be delivered quickly.

List TODO and NOT‑TODO items to show awareness of what cannot be done now.

Basic Steps of System Design

What is the fundamental goal of the feature?

What are the non‑functional goals?

Data flow (API) / User flow – list all required APIs and user interactions.

MVP – core feature list, core APIs, core interactions, core interfaces.

UI component states and how to separate UI from logic.

Core specifications based on the MVP – identify key problems and tricky parts.

Basic Steps of Product Design

What is the goal of the web service or web app?

Relation to native apps – is this a replica, a mobile version (H5 or mini‑program), or a new PWA/hybrid?

Target platform – mobile, desktop, or installable app?

Is a mobile‑first approach needed for desktop?

Is SEO a concern? – decide between SSR or SPA.

Number of services and team size.

Define MVP – core feature list, core APIs, core interactions, interfaces.

Highlight service and developer experience (DX) improvements.

Future roadmap – TODO and NOT‑TODO list.

Future Assumptions

Assume daily/monthly active users (DAU/MAU).

Assume number of interactions per day.

Assume a tolerable payload size (e.g., 300 KB) for performance.

Assume average API response time (e.g., 100 ms).

Large Diagrams

While system design may not always require diagrams, product design often does.

Draw charts or outline structures.

Show data flow / user interaction flow (validated with the client).

Main Challenges and Bottlenecks

Two concrete performance challenges:

Smoothness – aim for a lag‑free experience.

Instant response (page stack / global state / API cache).

Instant forward navigation (framework / loading indicator / first paint).

Instant interaction response (accessibility, passive listeners, design guidelines).

Native‑like animations, transitions, gestures.

Native UI components.

Speed / Performance

Preload / prefetch.

Code splitting + skeleton loading.

Cache / CDN static assets.

Service Worker for offline caching.

Lazy loading.

SSR / initial data feedback.

Viewport‑only updates (API, etc.).

Image Optimization

Compression.

Lazy loading / placeholders.

Progressive images (blurred placeholders).

Sprite images.

Use SVG for icons (scalable).

Cache / HTTP/2 (browser cache, CDN).

API Strategies

Three ways to handle real‑time data updates:

Multiple HTTP headers / empty‑header polling (client‑pull) – e.g., stock apps.

WebSockets (server push) – e.g., chat apps.

Server‑Sent Events (SSE) – e.g., stock apps.

Backend‑for‑Frontend (BFF) – API aggregation:

Call relevant micro‑service APIs to gather data.

Format data for front‑end consumption.

Send formatted data to the front‑end.

GraphQL – provides a complete, understandable description of API data, allowing clients to request exactly what they need.

Cache / HTTP‑2 – caching of API responses.

Trade‑offs, Alternatives, TODO

Nothing is perfect.

List possible improvement ideas.

If more time is available, think deeper about desired features.

Google’s RAIL Performance Model

RAIL stands for Response, Animation, Idle, Load . It categorizes user interactions and sets context‑specific performance goals.

1) Response

Process user input within 50 ms to keep the overall response under 100 ms.

Not all interactions (e.g., touch‑drag, scroll) fit this window.

If processing exceeds 50 ms, provide feedback to the user.

2) Animation

Generate each animation frame within 10 ms (budget ~16 ms per frame at 60 fps, leaving ~6 ms for rendering).

Goal is visual smoothness; users notice frame‑rate changes.

3) Idle

Maximize idle time to increase the chance of responding to input within 50 ms.

4) Load

Deliver content and become interactive within 5 seconds; slower loads increase bounce rates.

Key Metrics for Each Visited Page

DOMContentLoaded – time to load HTML and start rendering.

Load – time when all resources are fetched and parsed.

First Contentful Paint (FCP) – when the first element appears in the viewport.

First Meaningful Paint (deprecated) – time for main content to appear.

Speed Index – visual progress speed of page rendering.

Time To Interactive (TTI) – time until the page is fully interactive.

First Input Delay (FID) – latency between first user interaction and browser response.

Total Blocking Time – total time main thread is blocked between FCP and TTI.

Largest Contentful Paint (LCP) – when the largest element in the viewport becomes visible.

Facebook’s Five Public System‑Design Values

Bold – take risks needed to achieve great things in a fast‑changing world.

Impact‑focused – solve the most important problems, not secondary ones.

Open – believe that those with details make better decisions.

Build social value – connect the world through products.

Move fast – value rapid action and learning over slow, missed opportunities.

Conclusion

The article has covered the complete system‑design process for applications, including methods to evaluate design feasibility and performance.

Hope this guide is useful – thank you for reading.