為了提高使用者體驗，客戶每次輸入乙個字元時，後台資料庫會接收到從前台發來的請求，將符合條件的商品列表返回給前台。使用者不需要將所有的字元輸入完畢後再手動點「搜尋」按鈕。
現在你負責前台web page和後台資料庫查詢響應的設計，請你盡可能多的列出在該場景的前後臺設計裡，需要考慮到的邊界條件和錯誤處理。也就是說，請你盡可能多的列出理論上有可能會導致前後臺應用異常或者崩潰的特殊情況，並列出可行的解決/避免方案。
分析：來面試的人員可能有的專案裡以做前台/ui為主，有的是更偏後台一些，這道題前後臺都有，所以我們可以根據面試者的背景，在評分時更看重其專案裡focus的那塊。
前台：題目裡只提到了瀏覽器，考察面試者是否想到
(1) 前台**需要支援市場上主流的瀏覽器，
(2) 對於支援的瀏覽器，通過市場調研或者與客戶溝通，明確對於指定的瀏覽器，需要支援的版本
需要支援哪些os？
使用者輸入產品名稱後，前台**應做一定的encode處理，避免指令碼注入。確保使用者輸入任意的名稱，前後臺應用均不會崩潰。
商品購買數量必須合法( 必須大於0, 小於等於該商品庫存 ). 如果輸入數量不合法，在前台通知使用者。
前台輸入的「流量控制」. 如果每個字元輸入都會產生乙個到後台的查詢請求，如果客戶以極快的速度t連續輸入n個字元，則前n-1個請求都是無效的，對後台產生了不必要的負載。為了避免這種情況，可以設計在時間視窗t內，前n-1個請求的cancel機制，比如為時間視窗t維護乙個請求佇列，當時間到達時只傳送佇列尾部的請求。
注：這個有點偏效能優化的topic了？不過也可以說成，如果不這樣做，在高併發情況下，容易把後台資料庫搞死
購物車的容量限制。我們不能讓使用者無限制的往購物車裡加商品。
只要面試者考慮到這種情況即可-考察應用程式裡多使用者請求的處理。
使用者開啟第乙個web page將商品a加入購物車，再開啟第二個web page，將商品a從購物車中刪除，此時購物車中實際上已不存在商品a。
然後再回到第乙個web page，試圖從購物車中將商品a移除。
需要保證在這種情況下，前台應用不會崩潰。
客戶在購物車裡加入了大量的商品，由於某種原因瀏覽器程序崩潰了，當重新登陸後，之前已經加入到購物車裡的商品是否仍然存在？
只要考慮到這種可能的情況即可。
其他和http相關的比如session/cookie的就不列在這裡。
sql 注入的防止（雖然前台已經做過類似的encoding）
如何保證同一時間高併發請求到來的情況下，資料庫不會崩潰？流量控制？負載均衡?分布式？後台應用層加buffer？
返回搜尋結果的分頁/max hit - 避免一次返回太多資料讓前台崩潰，降低後台記憶體開銷
請程式設計實現乙個資料物件的容器，該容器既能夠提供快速索引容器中物件的能力，又能夠提供按照物件放入容器中的順序來依次遍歷物件的能力。請進一步實現容器能夠按照物件的排序規則來遍歷容器中物件的能力。
讀取乙個檔案，列印出檔案裡出現次數最多和次數最少的字串本身及其出現個數。
我第一家網際網路公司產品開發周期
從開始上班到如今，也快滿一年了，在這，就談一下軟體開發的幾個階段。各公司應該有不同的名稱，可是開發流程較完整的公司應該是會有以下的幾個階段。以下是我對這幾個產品週期階段的理解還有心得，還請大家不吝不吝賜教 需求評審 在此階段。產品經理 pm 會提出新的需求，比方說軟體的一些新功能，並講解此需求的動機...
國內網際網路公司季報
阿里 2018.6 2018.9季報 第一財季營收809.2億元人民幣，市場預期808.8億元人民幣。第一財季營收同比增長61 連續6個季度保持超過55 的高速增長。以及利潤相關 阿里巴巴稱，第一財季非美國通用會計準則下盈利達到201.01億元，同時，由於螞蟻金服估值大幅增加，授予員工的螞蟻金服相關...
FW 網際網路公司職位
網際網路公司的職位通常都差不多，基本上都有技術部和市場部。而通常情況下，各公司會根據自己的情況，採用不同的組織架構。有些公司會選擇使用扁平式的組織架構，就是各職能單位各自獨立，彼此之間通過管理人員與部門員工的頻繁溝通 呼應，來解決各種問題 有些公司則選擇專案組式的組織架構，將專案所需的人員集中在乙個...