tolerance, scalability and correctness are five important design decisions for real-time data stream processing systems. Two architectural styles for real-time data processing are the Lambda architecture ([[http://lambda-architecture.net](http://lambda-architecture.net)]([http://lambda-architecture.net](http://lambda-architecture.net)), by [PERSON], creator of Storm) [10] and the Kappa architecture ([[http://kappa-architecture.com](http://kappa-architecture.com)]([http://kappa-architecture.com](http://kappa-architecture.com)), by [PERSON], from LinkedIn). They both deliver fault-tolerant and scalable data processing with support for incremental data updates. However, the Lambda architecture has received some fair criticism [11] on the coding overhead due to the necessity of maintaining two code bases for the batch and speed layers. The Kappa architecture aims to avoid this pitfall by handling both the real-time data processing and the reprocessing of (historic) data using a single stream processing engine. Beyond this observation, many data processing platforms that follow a Lambda or Kappa architectural style also often assume a single albeit distributed and scalable storage system for processing large amounts of data. However, the design trade-offs of monolithic Lambda and Kappa architectures may jeopardize the flexibility to quickly change the data processing workflows to evolving needs and requirements. That is why enterprises such as Netflix are adopting microservice architectures [12; 13] to build data-intensive applications, mainly to address managerial concerns with the development and deployment life cycle of monolithic service architectures. Proposed by [PERSON] and [PERSON], the basic principles behind microservices are that (1) a microservice only deals with a restricted and clearly-defined set of functions, (2) each microservice is developed independently of the most appropriate programming language, (3) each microservice is stateless and manages its own database and (4) each microservice runs autonomously in its own process. With microservices, applications are developed as compositions of smart data processing endpoints and dumb pipes, as depicted in Figure 1. The low coupling and high cohesion of such distributed choreographies of independent microservices simplify the introduction of new functionalities in the data processing workflow, and they allow for each microservice to be developed, deployed, modified and scaled out independently, a clear advantage for dynamic cross-enterprise collaborations [14]. In this paper, we research the feasibility of decentralized microservice architectures to develop flexible and scalable security analytics applications. More specifically, we investigate to what extent microservices can be leveraged to realize a policy-based access control architecture where the access policies are defined in terms of data-intensive authorization decisions. For example, multiple microservices may process different streams of data and contribute their risk assessments to influence the final and joint decision whether a subject is granted or denied access to an online resource. In such a deployment scenario, each microservice carries out its own risk assessment--using a rule engine, complex event processing, statistical analysis, machine learning algorithms, etc.--based on the parameters it receives or monitors and the historic information previously processed and stored in its own database. These individual assessment outcomes are then combined in an authorization policy that evaluates a set of authorization rules to come to the final access control decision. Figure 1: High-level decomposition of a microservice based application with various user interfaces (UI) and application programming interfaces (API).