Tech Trusted


Architecture for Data-Intensive Applications

Most of my client’s applications code is for parsing, caching, storing, aggregating, protecting and sharing data! It is not the kind of code that demands CPU power (except for the garbage collector).

Martin Kleppmann, in his excellent “Designing Data-Intensive Applications” book, describes this kind of applications as “Data-Intensive Applications.”

What are Data-Intensive Applications?

Following Kleppmann’s definition, Data-intensive applications are these where the more significant problems are:

  1. the amount of data,
  2. the complexity of data,
  3. the speed at which data is changing.

Exact what I have seen in the field.

Data-Intensive Applications building blocks

The standard building for data-intensive applications are:

  • databases – to store data so that they, or another application, can find it again later;
  • caches – to speed up reads remembering the result of expensive operations;
  • message brokers – for message exchanging between processes and/or stream processing;
  • batch processors – crunch big amounts of data

Besides of that, there are a lot of application code to orchestrate all this work.

Data-Intensive Applications Architecture

Considering archictecture as:

The structure of components, ther inter-relationships, and the principles and guidelines governing their design and evolution over time. (ISO/IEC 42010:2011)

Considering what we have seen, we could represent Data-Intensive applications as follows:

This diagram (adapted from the book), provides us with an excellent blueprint for a generic “Data-Intensive Application” architecture. Also, indicates the components we have to write.

PAUSE: Why I love RavenDB?

RavenDB is a powerful NoSQL database that provides built-in support for MapReduce, Full-Text indexing and more. Because of that, when using RavenDB, the need for separeted caching and full-text indexes is reduced and I need to write less code.

COMING BACK: Why is this view important?

Most of the code that I have seen do not have a proper separation of concerns. For example, there are a lot of caching logic mixed with reading data, updates to the full-text search indexes combined with the write operations, and so on. Unfortunately, the result is code hard to read, understand and, consequently, costly to maintain.

Call for Action

What about your code? Is that “data-intensive”? What about the organization of the components? Would it be something like I shared here?

Share your thoughts in the comments.

Compartilhe este insight:

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mais insights para o seu negócio

Veja mais alguns estudos e reflexões que podem gerar alguns insights para o seu negócio:

A aquisição de novos clientes é importante para o crescimento. Entretanto, a manutenção dos clientes atuais tende a ser mais...
Um dos benefícios mais bacanas do programa MVP é o direito a participação no MVP Global Summit – evento anual,...
Tem coisas que a gente até sabe, mas ignora pela vaidade… Uma das features mais aclamadas do Microsoft Teams, para...
In this post, I will show how to do your first steps with OpenCV quickly using Visual Studio 2017 and...
Eu sei que sou privilegiado, em última instância, por poder oferecer, através do meu trabalho, algo que a sociedade valoriza....
I talked about microservices at two conferences last week. In both opportunities, the attendees asked me about how to implement...