IT 互联网公司往往会用不同的应用程序来处理各种业务。比如内部使用的企业资源规划 （ERP）系统、客户关系管理（CRM）系统，还有面向客户的Web应用程序。这些系统一般都会进行分层设计：“计算层”就是应用程序本身，用于数据计算和处理；而“存储层”往往是传统的关系型数据库，用于数据存储。
这里的应用程序在处理数据的模式上有共同之处：接收的数据是持续生成的事件，比如用户的点击行为，客户下的订单，或者操作人员发出的请求。处理事件时，应用程序 需要先读取远程数据库的状态，然后按照处理逻辑得到结果，将响应返回给用户，并更新数据 库状态。一般来说，一个数据库系统可以服务于多个应用程序，它们有时会访问相同的数据库或表。
这就是传统的“事务处理”架构。系统所处理的连续不断的事件，其实就是一个数据流。 而对于每一个事件，系统都在收到之后进行相应的处理，这也是符合流处理的原则的。所以可 以说，传统的事务处理，就是最基本的流处理架构。
对于各种事件请求，事务处理的方式能够保证实时响应，好处是一目了然的。但是我们知 道，这样的架构对表和数据库的设计要求很高；当数据规模越来越庞大、系统越来越复杂时， 可能需要对表进行重构，而且一次联表查询也会花费大量的时间，甚至不能及时得到返回结果。 于是，作为程序员就只好将更多的精力放在表的设计和重构，以及SQL的调优上，而无法专 注于业务逻辑的实现了——我们都知道，这种工作费力费时，却没法直接体现在产品上给老板 看，简直就是噩梦。
