System Design

Framework
Overview
• The role of the System designer is to define the
architecture, components, modules, interfaces and data
for a system.

• It is a skill that is dependent upon all the things you

have learned and have continued to learn. Its an ever-
evolving world.
 System Development Areas
For System Design the focus is on these two areas

Ex. Messaging
Queues, Aggregators,
OOP/Low Servers, etc.
Product Infrastruct
Level
Design ure Design
Design

Though the system

design focus on the
other two areas, it Front End
needs to keep these Design
Ex. Designing
areas in mind. Wikipedia, Youtube,
Nonfunctional requirements like etc.
security, scalability, maintability, It’s a simple picture but there is much hidden in
etc. Also need to be discussed. each of these bubbles. It is the place where the
conversation of system design begins. What
we need is a workflow to help us organize and
communicate about the design.
 What do we need for system
design?
• It’s really the same as what you needed for programming.
• Fundamentals of Programming This will apply to working on your
• A precise specification of what we want design. Finding critical items and
• Verification that we got what we want working thru them before doing lots
• The ability to make progress in small steps.
of other design work is important.
• Delivered system is maintainable, scalable and supportable
Keep complexity manageable.
• System design is just a higher level of abstraction, less restrictions and
incorporates more things like servers, networks, etc.
• As someone who has programmed you have done this just a more constrained level.
• System design is just leveraging your experiences
• What is new is the breadth and scope
• Working at a higher level of abstraction
• More horizontal thinking then vertical (but your vertical experience matters)
• Leverage your knowledge of existing technologies, architectures and products. (this is
often the part that worries job interviewers)
• A lot more social interaction and communication. (This is key, it's not a solitary
System design is just an evolution in your skill set. It leverages what you know, what you
process)
have continued to learn over time and communicate with a customer on what is needed to be
done and give them the confidence you can get it done. But how do we apply a rigor to all
this to get to an end product?
Merging this to create a solution

Existing
Products
Customer Your
(Keeping up
Needs Experiences
with existing
technology
products)

• At the start these bubbles

User Needs
(Which can be New are disconnected.
Technologies • The job is to bring them
different than
the (Keep together into a workable
customer!) current!) design.
• So now we talk about the
rigor, the framework to get
there.
• Gives you a place to
Framework (0 of 6)
• Preliminary
• Not often discussed in published articles about frameworks is a basic
categorizing of the system to be built
• There are two basic systems
1. Clean sheet of paper
• This can be very exciting but can also be a freewheeling mess if order is not quickly
established and scope is not maintained.
• This often involves talking to the stakeholder (customer) in helping them discover what can
and cannot be done.
2. Existing system, often a broken system
• If you are not familiar with the system, it will require the customer to ‘train’ you on what
they want done.
• Understanding this starts scoping the problem.
• Cost and schedule is something that a system designer should be mindful
about.
• Not covered here but the more you know about this the better.
• This can really limit what you can do
 Framework Guide for System Design
This gives you a place to start. This is what should
be in your head when you have the conversation
with someone who is looking for a new system.
Requiremen Functional Requirements Though it looks like a step wise refinement, its not
ts Non-Functional Requirements really. There is not problem with doing some things
together, like data flow and high-level design. Or
Core
going back and adjusting something that wasn’t
Entities
working as hoped.
API / These are just the parts that should be covered.
Interface

Data Flow

High-level
Design

Deep Dives
 Requirements (1 of 6)
• Functional Requirements
• The "what" of a system by describing its behaviors, features, and functions, and they are
used to ensure the final product meets user needs and expectations.
• Examples:
• Online banking. Users must be able to log in with a username and password and check their account
balances
• Food delivery app. Users can browse menus, place orders, make payments, and track orders in real time.
• Non-Functional Requirements
• Define the quality attributes and constraints of a system, specifying how it should perform
rather than what it should do.
• Examples:
• Performance: A web page should load in under one second. A system must support 1000 concurrent users.
• Security: All sensitive user data must be encrypted.
• Reliability. The system must be available 99.9% of the time. Recovery from failure with 15 minutes.
• Scalability. The system should be able to handle a growing user and data volume over time without
significant performance lose.
• Maintainability. The code should be well documented and modular to allow for easier updates.

These are two very different areas of the system.

Both impact your design.
More on Requirements (and what
you should start thinking about)
• As you are collecting this info you should be already
thinking about how to partition the system.
• Start drawing things up in your notebook
• Take lots of notes.
• Think about systems you know or worked on and start
looking now for similarities.
• Use that to guide your questions.
• Think about technology you may need to get this done.
• This will be derived from the non-functional requirements the
most
 Core Entities
• A primary, fundamental object or concept that represents a key component of the system's
domain
• Encapsulate both data and behavior and are the building blocks for the design
• Example:
• Online shopping app:
• Product
• User or customer ID
• Order
• Shopping Cart
• Social Media
• User – has attributes like a profile_pic, username, etc.
• Post - Content associated with the user
• Comment – Content associated with a post and a user. Limited to text.
• During the requirements and discussions with the customer these core entities need to be
captured.
• Generally, the customer is using these terms when they are talking. Or they are self evident.
• In System Design is a critical step.
• Create a clear mental model. That provides a shared understanding of the systems purpose.
• Guide data modeling to determine the underlying data structures.
• For OOP core entities often translate to classes, organizing code logically and help with maintainabilty and
scalability.
• Define reasonability's in what part of the system can and should manipulate the which data.
 API and other Interfaces
• These really are ‘stubs’ of where communication or some kind of service.
• Typically
• REST API
• Focused on application communication
• Resources
• Multiple endpoints
• Caching
• Fixed data structures
• GraphQL
• Is a query language and some tools.
• Works over a single endpoint
• Client driven data fetching
• Scheme and type system. Defines all available data and operations

• Usually, to start the REST API should be a good start to layout all your
resource communication.
• If you need more detailed data understanding then GraphQL is useful to help show
you design.
• These architectural styles are used to facilitate communication to everyone
in the design effort. You are not coding it.
 At this point…
• You should have in your notebook (or whiteboard):
• Functional Requirements
• Non-functional Requirements
• Core Entities
• API / Interfaces
• This is your starting process for the next phase.
• Just like in programming you are looking for patterns.
• The more patterns you learn about the easier this will get.
• Before you start with the next phase give yourself a moment to think
• Look for something that looks like some system you already know about
• Think about tech and architectures you are comfortable with and know that can be potentially
can be used here
• If possible, during the conversation of this data, you were starting to doodle some partitions and
architecture ideas.
• Remember just like in coding break things up into smaller pieces to help manage the
complexity. That is what system design is all about.

• What happens from here is you are going to start to bring the design to life!
Data Flow / High-Level Design
• This is where we start using graphical representation of the system design.
• This graphical image needs to support the functional requirements.
• When starting this design needs to be simple, clear and communicate to
others how the system is going to go together.
1. Identify major components from the functional requirements
• Represent this with a simple shape (box or circle)
• Avoid to much detail at this point
2. Define Relationships and interfaces
• How components above will interact with one another (data flow)
• Use lines between the components (label with API info)
3. Preliminary layout
• Usually easier to have user components on left and backend components on right
 Difference between Programming
and HLD

• Describes the overall system architecture • Describes class structures, methods, and
• Focuses on major modules and data flow relationships
• Identifies external interfaces • Defines database schema in detail (tables,
• Helps in choosing the tech indexes, keys)
• Shows services, databases, queues, APIs • Specifies API request/response formats
• Documents business logic and algorithms
Example

Source: [Link]
diagram/
Another example: Distributed
messaging queue
Deep Dive
• Analyze and refine the high level design.
• Identify potential issues and areas that need more
consideration.
• Discuss key components to ensure they meet
requirements
• Explore tradeoffs and reasoning behind design choices,
why other choices were no chosen.
• Anticipate problems such as bottlenecks or data
consistency under high loads for example.
Example
Example Music Streaming App
• Functional Requirements:
• User Management: The system must support user registration, login, and profile
management. (Mapped to: User Authentication & Profiles)
• Music Catalog: The system must store and manage a large library of music
tracks, including metadata like artist, album, and genre. (Mapped to: Music &
Metadata Database)
• Music Streaming: Users must be able to play (stream) audio tracks on their
mobile devices in real-time. (Mapped to: Streaming Servers & CDN and Data &
Audio Streams)
• Offline Access: The mobile app must be able to download and store music locally
for playback without an internet connection. (Mapped to: Local Storage /
Caching)
• Payment Processing: The system must integrate with a payment service to
handle subscriptions or purchases. (Mapped to: Payment Gateway)
• Social Sharing: Users should be able to share their activity or connect their social
media accounts. (Mapped to: Social Media integration)
Example:
Music
Streaming
Non-Functional Requirements
• Scalability: The backend infrastructure must be able to handle a large
and growing number of users, songs, and concurrent streams.
(Mapped to: Cloud Services / Backend Infrastructure)
• Performance (Low Latency): Audio streaming must start quickly with
minimal buffering. This is achieved by distributing content
geographically. (Mapped to: Content Delivery Network (CDN))
• Availability: The service must be highly available (minimal downtime).
(Mapped to: Cloud Services)
• Security: All communication, especially user data and payment details,
must be encrypted. (Mapped to: HTTPS/SSL shown on the data stream)
• Interoperability: The system must be able to connect and
communicate with external, third-party services. (Mapped to: Third-
Party Integrations)
Data Entities
• These are the main objects your system needs to store and manage, typically
represented as tables in your "Music & Metadata Database" and "User
Authentication" services.
• User: Represents the individual using the [Link] Attributes: UserID, Username,
Email, PasswordHash, SubscriptionStatus (e.g., free, premium), ProfileImageURL.
• Track: Represents a single song.
• Key Attributes: TrackID, Title, Duration, Genre, FilePath (link to the file on the
CDN), AlbumID, ArtistID.
• Artist: Represents the music [Link] Attributes: ArtistID, Name, Bio,
ArtistImageURL.
• Album: Represents a collection of [Link] Attributes: AlbumID, Title,
ReleaseDate, CoverArtURL, ArtistID.
• Playlist: A user-curated list of [Link] Attributes: PlaylistID, Title, Description,
OwnerUserID (a foreign key to the User).
API Endpoints
• These are the "routes" or "commands" the Client
(Mobile App) uses to talk to the Server (Backend
Infrastructure). This is commonly a REST API.
• Authentication API (Handles the "User Authentication"
box)
• POST /auth/register
• Action: Creates a new user account.
• POST /auth/login
• Action: Authenticates a user and returns a secure token (e.g., a JWT) for
future requests.
• POST /auth/logout
• Action: Invalidates the user's session token.
API continued
• User & Playlist API
• GET /users/me
• Action: Gets the profile details for the currently logged-in user.
• PUT /users/me
• Action: Updates the user's profile (e.g., change username, update profile picture).
• GET /users/me/playlists
• Action: Gets all playlists created by the user.
• POST /playlists
• Action: Creates a new, empty playlist.
• GET /playlists/{playlist_id}
• Action: Gets the details and list of tracks for a specific playlist.
• POST /playlists/{playlist_id}/tracks
• Action: Adds a specific track (e.g., by sending {"track_id": "123"}) to a playlist.
• DELETE /playlists/{playlist_id}/tracks/{track_id}
• Action: Removes a track from a playlist.
API continued
• Music & Metadata API (Handles the "Music &
Metadata Database" box)
• GET /search?q={search_term}
• Action: Searches for tracks, albums, and artists matching the search_term.
• GET /tracks/{track_id}
• Action: Gets all metadata for a single track.
• GET /albums/{album_id}
• Action: Gets metadata for an album and the list of tracks it contains.
• GET /artists/{artist_id}
• Action: Gets the artist's details and their top tracks or albums.
• GET /browse/featured
• Action: Gets curated content for the "home" or "browse" screen (e.g., new
releases, popular playlists).
API continued
• Streaming API (Handles the "Streaming Servers & CDN"
box)
• GET /stream/track/{track_id}
• Action: This is the most important one. It returns the actual audio
stream (e.g., an MP3, AAC, or Ogg file). The server verifies the user's
authentication (and subscription) before redirecting to the CDN or
streaming the file directly.
• POST /download/track/{track_id}
• Action: (For premium users) Allows the app to download the track for
Local Storage / Caching and offline playback.
Deep dive
• Scalability:
• How it's met: This is the primary function of the Cloud Services / Backend
Infrastructure. By using a cloud platform, services like the API Gateway, User
Authentication, and Databases can be "horizontally scaled"—meaning more
server instances are automatically added as user traffic increases. The CDN
is also an inherently scalable service designed to handle millions of
concurrent requests globally.
• Performance (Low Latency):
• How it's met: This is handled by two key components:
• Streaming Servers & Content Delivery Network (CDN): The CDN is the most critical part
for performance. It stores copies of audio files in servers geographically close to your
users, so a user in London streams from a London-based server, not one in California.
This drastically reduces buffering and start-up time.
• Local Storage / Caching: For songs the user plays often or explicitly downloads, storing
them on the device (caching) means playback is instantaneous and doesn't rely on
network speed at all.
Deep Dive continue
• Availability:
• How it's met: This is another core benefit of the Cloud Services /
Backend Infrastructure. Cloud platforms are designed for high
availability by running services across multiple data centers. If one
server or even an entire data center fails, traffic is automatically
rerouted to a healthy one, ensuring the app remains online and
functional for the user.
• Interoperability:
• How it's met: This is the specific purpose of the Third-Party
Integrations block. The API Gateway acts as the front door,
allowing controlled communication with external services like
Social Media (for "Login with Facebook") or the Payment Gateway
(to process subscriptions).
Deep Dive
• Security:
• How it's met:Data & Audio Streams (HTTPS/SSL): This label
explicitly shows that all communication between the mobile
app and the backend is encrypted. This prevents
eavesdropping and "man-in-the-middle" attacks.
• User Authentication & Profiles: This service is responsible for
securely handling user logins, passwords (which would be
hashed), and managing secure session tokens.
• Payment Gateway: By using a third-party gateway, the app
avoids handling or storing sensitive credit card information,
offloading that security risk to a specialized, compliant
service.