# 人資系統

---

> fliQt 技術挑戰

面試者： Daniel Wang <br>
信箱： igs170911@gmail.com <br>
linkedin: [點我](https://www.linkedin.com/in/hsing-hua-wang-3035081a0/)

---

### 目的
為了面試而建立的專案，了解人選(Daniel Wang)
1. 對於 api 的設計能力
2. 對於功能的理解以及討論能力
3. 資料庫設計的能力（包含結構設計，遷移，以及）
4. 對於快取使用的時機（例如如何防止雪崩，穿透，以及同時訪問等）
5. 對於 golang 專案目錄及架構的了解程度(UT, makefile, docker)

---

### 說明
本次範圍主要會把所有下列項目做完 
1. API 設計完成
2. 資料表結構，以及相關索引
3. 完整架構的部分

部分功能因為時間關係，不實作，但是會開出 Interface 出來示意，架構會趨於完整可以後續討論。

---

## 限制與假設
需求需要詳細被討論，因為沒給定，我先假想，有需要可在面試時進一步討論

### 非功能性需求

#### 使用者數量範圍
1. 初期階段：
	* 支援 500 ~ 1,000 名員工，涵蓋中小型企業或部門需求。
	* 用戶主要為 HR 員工、部門經理，以及少量系統管理員（約占總使用者的 10%）。
	
2. 成長階段：
    * 設計需具備可擴展性，支持 5,000 ~ 10,000 名員工，適合中型企業。
    * 具備支援更多 HR 人員和部門經理同時操作的能力。
3. 長期目標：
    * 最終設計需能支持 50,000 ~ 100,000 名員工，覆蓋大型企業的需求。
    * API 架構需能水平擴展，支持分布式部署及跨區域的數據一致性。

---

#### API 負載假設

1.	TPS（每秒事務數，Transaction Per Second）
   * 初期設計目標：支援 100 ~ 200 TPS，即每秒最多處理 200 次完整請求事務。
   * 成長階段：需擴展至 500 ~ 1000 TPS。
   * 長期目標：支援 5000 ~ 1,0000 TPS，需搭配水平擴展與快取優化。


### 目前先設計支援初期階段因應人力，資源，以及時間考量下較為可行的 standalone 模式，但也要考慮之後可以拆成為服務的方案，以利後續擴充

### 功能性需求