事件模型對於提高系統性能起到關鍵的作用，特別是網絡IO模型，如EPOLL和IOCP已經深入人心。還有比較少爲人知的事件處理引擎，用於高性能的商業邏輯實現。網絡IO模型位於系統底層，深入研究的人爲數不多，幸好接口很簡潔，綁定句柄和事件，當事件觸發時，會通知上層應用。在網絡IO模型中，可以管理大量的句柄，但事件卻只能是有限的幾種，一個EPOLL句柄只能算一個觀察者。
在現實生活中的網絡購物，在購物平臺下單後，物流會自動配送。在到達後，快遞小哥會通知我們，不需要我們隨時候着【阻塞模式】，或者定期打電話問到了沒有【輪詢模式】，正常要幹嘛還是幹嘛去。一年一度的購物狂歡節雙11馬上要到了，我們會在多個店鋪購物，甚至每個店鋪都可能下多個訂單，完全看心情。在我們接到快遞小哥通知時，就是多個事件。這個事件的數量依賴於我們的購物瘋狂程度。與此同時，每個網店乃至於每個熱銷商品，又可能被無數個購物者關注。
我們知道，在真實的場景中，事件源、事件、觀察者他們之間是天然的多對多關係。一個事件源可以觸發多種事件，比如某個明星的花邊八卦；而每個事件源又可以被多個觀察者關注，比如近期關於李詠和金庸先生逝世的消息；同樣，對於一個觀察者來說，也可能會同時關注多個事件，如近期的房價漲跌，或者孩子的教育資訊。
如上所述，在傳統的事件模型中，對事件的數量進行限制，限定一個觀察者，這樣簡化了整個模型實現，但與真實場景不符，就限制了它的應用範圍。特別是上層應用在處理，依然需要進行二次分發，而這些分發的處理邏輯其實和底層分發是一致。這在技術上，是一種浪費。
事件矩陣基於EPOLL的原理，將事件數量擴大爲無限制，而不止32位，同時允許多個觀察者。因此，事件和句柄就構成了一個對應矩陣 M(atrix) = E(vent) * H(handle)，這個對應矩陣是一個固定的對應矩陣，意味着每個句柄能夠觸發的事件是已知的，但每個句柄之間可以觸發不同的事件。這一點和傳統的事件模型是不同的。而事件矩陣的每個節點可以掛接多個觀察者，每個觀察者又可以關注多個事件源。於是，整個矩陣就形成一個複雜而巨大的矩陣M(atrix) = E(vent) * H(handle) * W(atcher)。幸好，通常這些關聯是稀疏矩陣。
數據親和架構爲了更好更快地管理數據，需要及時有效的監控到多種數據的變化，並予以統一調度，因此事件矩陣作爲基礎技術支撐。不單于此，事件矩陣更貼近於真實場景需求，因此可以將事件模型推廣到更大的應用場景。