System Design Tech Jargon for Product Leaders - Sketched & Explained

Looking for a way to understand technical jargon around full-stack, high-level system design?

Here’s how I’d sketch it out and explain it to non-technical product leaders.

Architecture – System design concepts you must know

All software products can be understood in 3 layers:

• Frontend User Interface (UI) layer to control what users see and interact with in your product
• Backend business logic layer for enforcing business rules 
• Persistence layer with databases (SQL or no-SQL) and media storage for storing data

The frontend and backend are connected via Application Programming Interfaces (APIs) which decouple the two layers so that they can be changed and updated independently of each other.

Communication - Build your technical fluency

The frontend is built using frameworks like Blazor, Flutter, REACT, or Angular.

For example, a shelter admin could use the Blazor administration portal to update pet details, while adopters view available pets through a Flutter app. 

The layout is created using design libraries like Material Design or Bootstrap.

The backend is built using frameworks and coding languages like .NET (with C#), Spring (with Java), or Node (with JavaScript).

For example, when an adopter clicks to initiate the adoption process, the backend may check whether this adopter has recently had a home inspection for a different adoption or needs to book one before proceeding.

Cloud-hosted backends can either use a:

• Server model like Azure App Service, Amazon EC2 (Elastic Compute Cloud), or Google App Engine
• Serverless model using cloud functions like Azure Functions, AWS Lambda, or Google Cloud Functions, often structured as event-driven microservices

For example, a backend microservice using an Azure Function might automatically send a confirmation email every time a home-inspection is booked.

The persistence layer is where data is stored. Data can be divided into 2 types:

• Details like pet names and breeds
• Media like pet photos and videos

Details like pet names and breeds are either stored in:

• Relational SQL databases like SQL Server or MySQL, which use structured schemas to store rigid data models
• Document databases like Firestore or MongoDB, which are schemaless and support flexible data models

For example, pet profiles (name, age, breed) may be stored in a relational SQL database, while notes from volunteers may be stored in a no-SQL document database.

SQL and no-SQL databases can be hosted in the cloud, for example:

• Azure SQL Database, Amazon RDS (Relational Database Service), or Google Cloud SQL for relational databases
• Azure Cosmos DB, Amazon DynamoDB, or Google Firestore for document databases 

Media like pet photos and videos are stored in the form of binary blobs (1s and 0s) in object storage like Azure Blob Storage or Amazon S3 (Simple Storage Service), or Google Cloud Storage (GCS), which excels at cheaply storing large files. 

For example, when a shelter uploads a new pet photo, it may be stored in Azure Blob Storage and fetched whenever someone views that dog's profile.

Planning - Build your technical intuition

Product requirements that only change one layer, like renaming a button on the frontend, have lower complexity and development effort.

For example, you could update the "Adopt" button to "Meet Meeee!" without needing to touch the backend at all. 

Product requirements that change all 3 layers, like introducing a new field, have higher complexity and development effort.

For example, introducing a new field to capture and store a pet's age requires a full-stack change and an update to the UI form, API, backend logic, and schema changes.

Note that in this specific example, there would almost certainly also be a corresponding full-stack required to display the pet's age on their profile which also needs an update to the pet profile UI card, API, and backend logic (for example, to distinguish between puppies and senior dogs).

Internal APIs (that is, those built by your team or other departments in your company) allow the frontend to be decoupled from the backend.

So if only one layer is changed–say, in the case of renaming a button–the backend remains unaffected, therefore there are no code changes needed.

This eliminates the possibility of introducing backend bugs and reduces the regression testing needed.

External APIs–say, the Google Calendar API used for scheduling pet home inspections–provide specialist functionality that you can integrate into your product to create richer experiences for your users without building the functionality from scratch.

For example, this means you can let users book home inspections using Google Calendar, without building your own calendar system.

These integrations allow you to rapidly develop new features at a fraction of the cost and it reduces the ongoing maintenance overhead since you trust that these APIs work as specified on the box.

Okay, and that's a wrap.

If you liked this style of sketched & explained knowledge share, either check out our post on API technical jargon sketched and explained, or download your FREE copy of our no-fluff ebook System design, APIs, and databases sketched & explained before lunch

Whenever you're ready, here's how I can help you

System design, APIs, and databases sketched and explained before lunch - FREE

Download your free copy of our ebook and build your intuitive technical fluency around 3 core concepts of building software products to earn engineers' trust FAST

Product Tech Sense™ Framework - PREMIUM

Request an invite to our limited-seats, premium, online live cohorts to master technical fluency, build technical intuition, and earn engineers' trust with our guided, high-touch sessions