ii.In the microservices approach, you could avoid the synchronous network request by caching the exchangerate locally in the service that processes the purchase. However, in order to keep that cache fresh, you wouldneed to periodically poll for updated exchange rates, or subscribe to a stream of changes—which is exactlywhat happens in the dataflow approach.This application code can do the arbitrary processing that built-in derivation func‐tions in databases generally don’t provide. Like Unix tools chained by pipes, streamoperators can be composed to build large systems around dataflow. Each operatortakes streams of state changes as input, and produces other streams of state changesas output.Stream processors and servicesThe currently trendy style of application development involves breaking down func‐tionality into a set ofservicesthat communicate via synchronous network requestssuch as REST APIs (see“Dataflow Through Services: REST and RPC” on page 131).The advantage of such a service-oriented architecture over a single monolithic appli‐cation is primarily organizational scalability through loose coupling: different teamscan work on different services, which reduces coordination effort between teams (aslong as the services can be deployed and updated independently).Composing stream operators into dataflow systems has a lot of similar characteristicsto the microservices approach [40]. However, the underlying communication mecha‐nism is very different: one-directional, asynchronous message streams rather thansynchronous request/response interactions.Besides the advantages listed in“Message-Passing Dataflow” on page 136, such asbetter fault tolerance, dataflow systems can also achieve better performance. Forexample, say a customer is purchasing an item that is priced in one currency but paidfor in another currency. In order to perform the currency conversion, you need toknow the current exchange rate. This operation could be implemented in two ways[40, 41]:1.In the microservices approach, the code that processes the purchase would prob‐ably query an exchange-rate service or database in order to obtain the currentrate for a particular currency.2.In the dataflow approach, the code that processes purchases would subscribe to astream of exchange rate updates ahead of time, and record the current rate in alocal database whenever it changes. When it comes to processing the purchase, itonly needs to query the local database.The second approach has replaced a synchronous network request to another servicewith a query to a local database (which may be on the same machine, even in thesame process).iiNot only is the dataflow approach faster, but it is also more robust to508|Chapter 12: The Future of Data SystemsWOW! eBook
