## 2 Materials and Methods  
This study is developed by following an approach based on the kappa architecture for big data as shown in Figure 1. The kappa architecture was first introduced by [PERSON] in 2014 ([PERSON] et al., 2016). It derives from the lambda architecture, which is considered one of the industry's best practices for scalable real-time big data processing ([PERSON] et al., 2016). Lambda architecture consists of three layers: batch layer, speed layer, and serving layer. The batch layer processes data and stores them to query precomputed data on demand instead of querying them on the fly. The speed layer processes data in real-time to compensate for the low latency updates in the batch layer. Thus, data are processed in a parallel manner in both layers. Finally, the serving layer stores the views from the previous two layers ([PERSON] et al., 2016). Kappa architecture is similar to the lambda architecture, with the difference that it does not include a batch layer, therefore it processes data only in real time ([PERSON] et al., 2016). In this context, the main characteristics of the kappa architecture are its simplicity and its flexibility in comparison with other big data architectures ([PERSON] et al., 2016); thus it is suitable for online processing of data flows ([PERSON] et al., 2016). Figure 1: Proposed kappa architecture. Source: compiled by authors with data from ([PERSON] et al., 2016). “Apache Kafka”, and “Apache Spark” are trademarks of the Apache Software Foundation. “TWITTER, TWEET, RETWEET and the Twitter Bird logo are trademarks of Twitter Inc. or its affiliates”. The proposed architecture consists of a real-time streaming layer that receives and processes new incoming data and a serving layer that stores data in MongoDB(tm) to be displayed or queried on demand. At the streaming layer, the processing is executed by means of Apache Kafka(tm)and Apache Spark(tm)which are helpful to process data in a distributed manner and consequently faster, in comparison with non-distributed approaches [34]. At the serving layer of the kappa architecture, the processed, modeled, and evaluated data coming from the real-time streaming layer are finally loaded into a database management system (DBMS), i.e., MongoDB(tm). In this case, as we handle huge volumes of unstructured data from Twitter, a document-oriented No-SQL database is better suitable than a traditional relational database due to its advantages regarding the horizontal scalability and the storage of unstructured data. The kappa architecture that we present is iterative. In the first iteration, single datasets from Twitter and CryptoCompare are processed and transformed in order to be related; thereafter, a second iteration is executed to classify the related datasets and obtain insights. In that context, data are collected as they are generated and then streamed, transformed, and stored in MongoDB(tm) from which datasets are queried. In this case, MongoDB(tm) serves as a batch that stores data from the last 120 s with the purpose of relating it, by considering a time span of one minute and therefore obtaining one register for each minute. Finally, the queried dataset is returned to the streaming layer to be processed by means of a machine learning approach; in this case, \(k\)-means clustering. \(K\)-means clustering is one of the most popular algorithms for unsupervised machine learning. It groups data with similar characteristics under a determined number of clusters while separating them according to their dissimilarities [35]. Clustering is defined as a method for finding homogeneous groups of data points in a dataset; in that sense, it allows the recognition of patterns in data [36]. For this study, data related to the two largest cryptocurrencies, according to their market capitalization, were collected, i.e., Bitcoin (BTC) and Ethereum (ETH) [7]. Data mining for the corresponding tweets was done considering publications made in English.