event sourcing / MQ(websocket) 配 rest API 難題

這篇單純寫給有緣人，其實是自己的 memo 就是了

client => ws(pub) => MQ => process(sub => pub) => MQ => ws(sub) => client

這是很簡單的異步處理結構，但如果配上 rest 會 block 的特性，則會很尷尬，類似

client => rest(pub) => MQ => process(sub => pub) ??

如果 rest 端得不到回傳到底是有沒有完成了？且照這結構 rest 端要弄個 block timeout 才行，MQ server 如果不穩時或掉封包，會得不到 response 還後 timeout 到底，最終交易是否有完成其實也是未知

所以這邊有兩種解法才是，或是 1 + 1 解法

client => rest(blocked) => process(sub + rest)

也就是 API 需求直接戳到 process 去，該 process 要開 rest + MQ sub，然後在記憶體內 merge jobs，當然需要過濾只有 CRUD 中的 CUD 且過了所有檢查才能戳著，這樣 process 噴了至少還是會 return result

然後 process 可以不回正確的 response package，可以再由另外一個回覆，類似

client => rest(blocked) => proxy process(job[s]) => process(return uuid[s]) => proxy process(package result[s]) => rest => client

這樣子就算漂亮了，然後還可以繼續擴增處理，類似 ... client 可能只需要知道 uuid 則 process 可以做隔離進行，成為兩條完整的平行線

client => ... => insert process(return uuid , pub uuid need trade) => MQ

MQ => trade process(got inserted jobs , then process)

這樣做隔離的話，就能回 client 完整的 pk 且不會掉才是，當然凡事是有缺點的，類似 insert 的為空的 job 可能會有 balance 的問題，能夠不真實扣帳，而 trade 可以取消 job 的狀況下 ... 應該都還能接受就是，單純要進行取捨而已