Capy 架構設計誌

我們知道 google reCAPTCHA 使用三次 connection 來顯示，但是我們想要減少到兩次，一次抓Javascript，一次抓圖片，但是如何驗證呢


2013/07之前，團隊的K夥伴利用IP位置來分辨不同使用者和captcha challenge，並在使用者回答或TTL之後去除掉這個challenge，但是這有兩個問題，一個是多人使用同個IP的情況，一個是同時開啟多個captcha可以讓任意答對的機率線性提高。

2013/07我加入Capy，我發現了第二個問題之後修改了設計，我們在client產生一個random token (challenge key)，利用此token產生和取得captcha image並記錄資料在資料庫等待被驗證，site owner使用我們的服務並且用同樣的token驗證，在極端的情況有個問題是，如果有人在取得captcha之前就先送出答案，server上會找不到這個key，我們選擇不理會此情況，到此為止我們都只需要兩次connection。

以上兩種設計都有共同的問題就是database heavy write，我們很早就需要做 database sharding ，感覺不會很難又很有趣，但是所有的文章都說 sharding 越晚做越好，不要讓初期的結構變複雜。

2014/01 一個實習生告訴我們可以使用 stateless 的作法，不需要放進database，這樣有一個大的好處，不需要做database sharding，但是也有一些壞處..