前陣子收到獵頭邀請進行了AmazingTalker資深軟體工程師的面試作業,作答如下,未進入下一階段。
A. 作品集審查
- 請分享 1-3 個您曾領導或在其中扮演關鍵角色的重要項目。
- 描述該項目解決的核心問題、您實施的解決方案以及所用的技術。
- 詳細說明您在項目中的角色和具體貢獻。
1. Microservices SAGA Orchestration Pattern
之前工作要依序呼叫多個外部API來實現某個功能交易,由於每個API呼叫是各自獨立,但功能必須全部成功或全部失敗,若中途出現問題必須進行補償操作,因此必須透過Orchestration Pattern來管理每個動作流程順序與失敗的補償。
- 擔任角色:工程師
- 具體貢獻:實作SAGA Orchestration Pattern
- 實作範例:https://github.com/matthung0807/go-demo/tree/create-order-saga-orchestration?tab=readme-ov-file
2. RabbitMQ重建連線
讓應用系統與中斷連線的RabbitMQ重建連線
- 擔任角色:工程師
- 具體貢獻:實作重建RabbitMQ連線
- 實作範例:https://matthung0807.blogspot.com/2023/01/go-rabbitmq-reconnect.html
3. Jenkins整合SonarQube
為了提高程式碼品質,導入SonarQube至Jenkins,在重新部署時會自動產生分析結果。
- 擔任角色:工程師
- 具體貢獻:實作Jenkins整合SonarQube
- 實作範例:https://matthung0807.blogspot.com/2024/02/jenkins-freestyle-project-integrate-sonarqube.html
B. 系統架構設計練習
- 需求說明:
- AmazingTalker 計畫開發一個新的「教師牆」功能,讓用戶能夠根據多個篩選條件選擇合適,且經過演算法排序的教師。
- 根據 https://amazingtalker.com/tutors/english 設計對應的後端架構,可大可小,至少包含排序演算法的功能,例:
- ⭐ 依照前台用戶各個不同語系的使用者,排名的公式演算法都不一樣,如何在最快的時間,算出這個使用者最容易購買的老師會很重要,例如我是中文語系用戶,過去24小時賣出給中文語系用戶越多的老師,排名越高
- 過去 1 小時、6 小時、1 天、7 天、1 個月的賣課表現, 賣課成交金額 x 時間越近 = 分數
- 老師過去一天是否有不良操作記錄(上課未到、訊息不回等等),作為扣分依據
- 老師未來 14 天內,有空可以上課的時間
- 國籍、會說語言是否符合使用者輪廓,例如台灣國籍喜歡外籍老師且會說中文
- 價格是否符合使用者國家之消費水平
- API 平均回應速度越快越好,最好低於 300ms,或至少不超過 1 秒,排序分數是隨時間在變動的,不可快取
- 線上教師數量 1 萬人 / 請求次數約 4000 rpm
- 任務要求:
- 設計支援此功能的系統架構。
- 不需要實作功能,概述系統的主要組件/模組以及如何滿足上述需求。
- 功能設計以架構與實作進行拆分,以包含自己的 2 人小組團隊,以三個月內能完成的前提之下,進行拆分架構與分配任務
- 提出至少一種架構方案,並就其優缺點進行比較,最後推薦一個您認為最佳的解決方案並說明理由
- 針對需求提出更多你的想法跟建議,幫助這個功能更完善,以及降低後需同伴開發上可能會遇到的問題
- 對於每個組件,估計開發時間和成本
- 識別潛在風險及其緩解策略
- 如果有需要Member進一步研究的領域,請指明具體的學習需求
- 技術環境:
- 不限制使用的技術
- 當前團隊有使用到:K8s、Rails Restful API(前端主要的API)、Golang微服務、AWS MySQL、AWS Redis 等
需求分析
- 用戶能夠根據多個篩選條件選擇合適,且經過演算法排序的教師
- 輸入/請求:多個篩選條件
- 輸出/回應:經過演算法排序的教師清單
- 不同語系的使用者,排名演算法不同,例如中文語系用戶,過去24小時賣出給中文語系用戶越多的老師,排名越高
- 賣出給會與用戶同語系的其他用戶越多的老師排名越高。
- 過去 1 小時、6 小時、1 天、7 天、1 個月的賣課表現, 賣課成交金額 x 時間越近 = 分數
- 每個老師都有成交金額紀錄與交易時間。給予每個距離時間權重以計算分數。
- 老師過去一天是否有不良操作記錄(上課未到、訊息不回等等),作為扣分依據
- 老師的不良操作記錄註記,若有給予扣分。
- 老師未來 14 天內,有空可以上課的時間
- 每位老師可排課的時間表
- 國籍、會說語言是否符合使用者輪廓,例如台灣國籍喜歡外籍老師且會說中文
- 用戶與老師在國籍和慣用語言的匹配性
- 價格是否符合使用者國家之消費水平
- 各國家消費水平定價紀錄表(定期更新)
- 教師價格超過該國家消費水平定價紀錄某個區間外降低權重
功能分析
搜尋條件
- 學習需求
- 上課時段
- 上課時間
- 預算區間
- 教師國籍
- 輔助語言
現有請求
{
"teach_language_url_name": "english",
"speak_language_url_name": "chinese",
"price_min": "21", // 預算區間(USD)
"price_max": "25", // 預算區間(USD)
"tag_id": "121-24",
"language_tag_id": "24",
"page": 1,
"locations": [
"US"
],
"priorities": [],
"is_active": false,
"time_slots": {
"session_weekdays": [
0, // 週二
2 // 週日
],
"session_time_ranges": [
"18-21" // 時間區間
]
},
"session_datetime_ranges": []
}
關聯資料表
會員
- 會員編號
- 國家編號(國籍)
- 語言編號(母語)
- 會員生日
- 會員時區
語言
- 語言編號
教師
- 教師編號
- 國家編號(國籍)
- 語言編號(母語)
- 教學經驗
- 教師時區
- 工作狀態
- 不良操作數
- 教師分數
語言
- 語言編號
- 語言
教師語言
- 教師編號
- 語言編號
課程
- 課程編號
- 教師編號
- 課程名稱
- 課程定價
課表
- 課表編號
- 教師編號
- 課程編號
- 會員編號
- 上課日期
- 上課時段
授課紀錄
- 授課編號
- 會員編號
- 課程編號
- 課程時數
- 交易金額
- 交易時間
國家
- 國家編號
- 貨幣幣別
- 消費水平權重
ER Model
系統架構
模組/服務
- 核心模組 - 系統、國家、語言資料設定
- 驗證模組 - 驗證外部請求
- 會員模組 - 會員資料管理
- 教師模組 - 教師資料管理
- 課程模組 - 課程資料管理
- 課表模組 - 課表資料管理
架構圖
任務分配
人力資源
功能設計以架構與實作進行拆分,以包含自己的 2 人小組團隊。工作單位為工作人天,三個月扣除假日可用工作天約為20天x3人x3個月=180工作天,扣除不確定因素x0.8為144工作天
工作分配
- 需求討論 - 2工作天
- 架構設計 - 5工作天
- 技術調研 - 10工作天
- 基本功能 - 10工作天
- 會員功能 - 10工作天
- 教師功能 - 10工作天
- 課程功能 - 20工作天
- 課表功能 - 20工作天
- 教師牆 - 20工作天/人
- 功能測試 - 10工作天
- 改善重構 - 20工作天
架構概述
用戶輸入條件可得的教師牆結果,主要是查詢「教師」資料表,但必須與其他資料表「教師語言」、「課表」、「授課紀錄」等關聯查詢才可依教師的賣客表現、不良操作數、可上課時間和與學員的語言匹配性等條件來取得教師排名和分頁結果。 應用層系統劃分成多個模組(微服務),每個模組的實例由K8S管理,實現平行擴展,前端的請求會透過附載平衡器分派給各後端服務實例。
沒有留言:
張貼留言