#1: What is System Design?

What this lesson covers

This lesson opens the series by defining system design as the placement of components in a distributed system and the way they interact to meet business requirements. It introduces three metrics used to evaluate every design decision in the course: simplicity, fidelity to the requirements, and cost effectiveness. The running example is a friend who sells T-shirts through social media and offline and wants to sell online. The video argues that the best first answer is an existing product, and moves from Amazon to Shopify because Shopify gives more control over the shop's look and offers payment and delivery integrations. The core principle is that an architect's job is to solve the business problem, not to build technology for its own sake. Three months later the shop makes around a hundred sales a day but has two problems Shopify cannot fix: no detailed delivery tracking, which makes support calls expensive, and a payment gateway that refuses international cards. This is where custom system design begins. The lesson sketches a payment page and a delivery tracking page linked from Shopify, backed by a server that stores payment and delivery state for each order. It explains APIs and API contracts using a JSON request that carries an order ID, describes an API as a function on the server that can be written in any language, and briefly mentions deploying code to a cloud server, optionally through GitHub-based automation.

• Designs are judged on simplicity, fidelity to requirements and cost effectiveness
• Use an existing solution such as Shopify when it meets the business need
• Build custom components only when existing providers block a real requirement
• An API contract defines the request format and the response a client can expect
• A server-side API behaves like a function and can be written in any language