你有沒有想過，每天滑的 IG、逛的蝦皮、玩的手遊，背後到底是怎麼運作的？
其實不管什麼網站或 APP，背後都有一套基本架構。
今天我們就用一張圖，把這些東西講清楚。不用怕，沒有艱澀的術語，就當作是在聽朋友聊天。
先看這張圖
中間那一圈是核心（交付、權限、運算、資料、儲存），外面包著的是品質保證（效能、資安、軟工）。我們一個一個來看。
交付：東西怎麼送到你手上？
簡單說，就是使用者要怎麼「拿到」這個產品。
有哪些方式？
API
讓不同系統可以互相傳資料的方式。
舉個例子：你在蝦皮買東西，結帳時選擇信用卡付款。蝦皮本身不會處理刷卡，它會把你的付款資訊送給銀行，銀行處理完再把結果送回來。這個「送出去、收回來」的過程，就是透過 API 完成的。
使用者不會直接看到 API，但你每次登入、付款、查物流，背後都有 API 在幫忙傳遞資料。
網頁（Web）
就是你打開瀏覽器看到的東西。Facebook 網頁版、Medium、各種部落格都是。
桌面程式（Desktop）
要下載安裝的那種。Windows 是 .exe 檔，Mac 是 .dmg 檔。最常見的就是遊戲，像 Steam 上的遊戲都要先下載。
手機 APP
從 App Store 或 Google Play 下載的。然後這邊還要再分 iOS 跟 Android，有時候兩個都要做。
如果你是 PM，第一件事要問什麼？
「我們到底要做什麼？」
是要開 API 給別人串？還是做網頁？還是做 APP？還是通通都要？這個沒搞清楚，後面都是白做。
權限：你是誰？你能幹嘛？
權限其實在處理兩件事：
- 驗證（Authentication）：確認「你是誰」— 你說你是小明，系統要怎麼確定你真的是小明？
- 授權（Authorization）：確認「你能做什麼」— 你是小明沒錯，但你能看別人的私密貼文嗎？能刪別人的留言嗎？
最常見的驗證方式就是「登入」。你輸入帳號密碼，系統核對正確後，就知道你是誰了。
兩種模式
Client to Server（從使用者端發起）
這是你看得到的登入過程：
- 打開網站，看到登入畫面
- 輸入帳號密碼，按下登入
- 或是點「用 Google 登入」「用 Facebook 登入」
不管是自己輸入帳密，還是用第三方登入，都是你主動在瀏覽器或 APP 上操作的，這就是 Client to Server。
Server to Server（伺服器之間互相驗證）
這是你看不到的，發生在系統的後台。
舉個例子：你登入蝦皮一次之後，關掉網頁，隔天再打開，通常還是登入狀態，不用重新輸入密碼。這是因為系統在背後自動幫你處理驗證，確認「這個人昨天登入過，還沒過期，讓他繼續用」。
另一個例子：有些公司內部系統會串接在一起，A 系統要跟 B 系統要資料，B 系統要先確認「A 系統有沒有權限來要這筆資料」。這個驗證過程也是 Server to Server，完全在後台發生，使用者不會知道。
簡單區分
運算：系統怎麼處理事情？
當使用者對系統發出請求（下單、發文、傳訊息），系統要決定「怎麼處理這件事」。不同的情境需要不同的處理方式，這就是運算模型在解決的問題。
Queue（佇列 / 排隊機制）
問題是什麼？
蝦皮雙 11，同時有一萬人下單，每筆訂單都要寄 Email 通知買家。如果系統試著「同時」寄出一萬封信，會發生什麼事？系統負荷不了，直接當掉。
怎麼解決？
讓這些任務排隊。第一筆訂單的 Email 先寄，寄完換第二筆，第二筆寄完換第三筆⋯⋯這樣系統不會被塞爆，每封信都能順利寄出，只是有些人會晚一點收到。
實際應用
- 發送 Email 或簡訊通知
- 處理大量訂單
- 產生報表（報表很吃資源，不能同時產生太多）
- 影片轉檔（上傳影片後，系統慢慢幫你轉成不同畫質）
Pub/Sub（發佈 / 訂閱機制）
問題是什麼？
你在 YouTube 訂閱了一個頻道，他有一百萬個訂閱者。當他發新影片時，要怎麼通知這一百萬人？一個一個去通知太慢了。
怎麼解決？
用「發佈 / 訂閱」的模式：
- 你按下「訂閱」，系統記住你對這個頻道有興趣
- 創作者上傳新影片（發佈）
- 系統自動把通知送給所有訂閱者
創作者不用知道有誰訂閱他，他只管發佈；訂閱者不用一直重新整理，有新內容系統會主動通知。
實際應用
- YouTube / IG / Medium 的追蹤通知
- 新聞 APP 的推播
- 股票 APP 的價格警示（「台積電漲到 X 元時通知我」）
- 團隊協作工具的訊息同步
WebSocket（即時雙向連線）
問題是什麼？
你在玩線上遊戲，你移動角色，對手要立刻看到；對手攻擊你，你也要立刻看到。如果有延遲，遊戲根本沒辦法玩。
一般的網頁是這樣運作的：你發出請求 → 伺服器回應 → 結束。如果你想知道有沒有新資料，要再發一次請求。這種「一問一答」的方式太慢了，不適合即時互動。
怎麼解決？
用 WebSocket 建立一條「持續連線的通道」。連上之後，雙方可以隨時互傳資料，不用每次都重新問。
就像打電話：接通之後，你隨時可以講話，對方也隨時可以回應，直到其中一方掛掉。
實際應用
- 線上遊戲（即時同步玩家動作）
- 聊天室、通訊軟體（訊息即時送達）
- 股票報價（價格跳動即時更新）
- 多人協作文件（Google Docs 多人同時編輯）
- 直播互動（彈幕、留言即時顯示）
快速對照
資料 vs 儲存：這兩個不一樣！
很多人會搞混，我們來釐清。
資料（Data）
就是「紀錄」，可以改一部分。
比如會員資料：
- 姓名：小明
- 電話：0912-345-678
- Email：ming@example.com
如果小明換電話，我們只要改「電話」那一欄就好，其他不用動。
儲存（Storage）
就是「檔案」，要改的話要整個換掉。
存的是什麼？圖片、影片、PDF、音樂檔⋯⋯這些靜態檔案。
實際例子
假設會員要上傳大頭貼，資料會怎麼存？
flowchart LR
subgraph 資料庫["📋 資料庫（會員資料）"]
direction TB
T1["name: 小明"]
T2["gender: 男"]
T3["email: ming@example.com"]
T4["avatar: /avatars/1"]
end
subgraph 儲存空間["🗂️ 靜態儲存空間"]
direction TB
F1["📁 avatars"]
F2["🖼️ 1.jpg"]
F3["🖼️ 2.jpg"]
F4["🖼️ 3.jpg"]
F1 --- F2
F1 --- F3
F1 --- F4
end
T4 -->|"路徑指向實際檔案"| F2看懂了嗎？
- 圖片本身（那張 .jpg 檔）→ 存在右邊的「儲存空間」
- 圖片的路徑
/avatars/1→ 存在左邊「資料庫」的 avatar 欄位
所以資料庫裡存的是「路徑」，真正的圖片在另一個地方。當網頁要顯示大頭貼時，系統會先從資料庫查到路徑，再去儲存空間把圖片拿出來。
資料庫又分兩種
關聯式（RDBMS）
資料之間有關係。會員連到訂單、訂單連到商品⋯⋯電商網站很適合用這種。
非關聯式（NoSQL）
比較彈性，適合需要快速存取或分散式的系統。
外圈：效能、資安、軟工
這三個在外圈，負責確保核心功能可以穩穩地跑。
效能
在意什麼？
- 網頁會不會很慢？
- 能撐住多少人同時用？
- 系統會不會卡頓？
資安
在意什麼？
- 會不會被駭？
- 資料會不會外洩？
- 密碼有沒有加密？
功能做得再好，如果很慢或不安全，使用者還是會跑掉。
軟工：工程師的基本功
軟工跟效能、資安一樣，都是在外圈，負責支撐整個系統的品質。
包含哪些事？
版本控制（Git）
程式碼怎麼管理、怎麼多人協作。
測試
怎麼確保程式沒有 bug。
部署
怎麼把程式上線、更新。
文件
怎麼讓其他人看懂你的程式。
這些是地基，沒做好的話上面蓋什麼都會歪。
總結一下
內圈（核心功能）
外圈（品質保證）
最後
下次當你在用任何網站或 APP 的時候，可以想一下：
- 這是用什麼方式交付給我的？
- 我登入的時候，背後發生了什麼事？
- 我上傳的照片，存在哪裡？
慢慢地，你就會對這些東西越來越有感覺了。