Talking about Microservices and the Source of Truth

content/code/microservices-source-of-truth.md

@@ -0,0 +1,60 @@
++++
+title = "Microservices: Where Is the Source of Truth?"
+date = 2020-02-17
+
+[taxonomies]
+tags = ["microservices", "state", "source of truth"]
++++
+
+When we are talking about a system, there is one point that we need to discuss
+where the "Source of Truth" of it is. In Monoliths, the source of truth is the
+storage itself. But where does it sit in a system that is composed by multiple
+parts?
+
+<!-- more -->
+
+Just to be clear here: What I mean by "source of truth" is whatever you can
+use to check if the system is producing the correct values. For example, in a
+pipeline to count how much users transfer in a CDN, the source of truth could
+be the logs (you can read the logs and check if the service responsible for
+summing the results is correct); in an e-commerce site, we could assume the
+source of truth to be the items in every invoice for the total revenue (if you
+sum all the items quantities by their prices, you'll get the revenue back).
+
+One important factor of a source of truth is that not only you can use it to
+check if your services are correct, but you can also re-apply its content back
+to the system to rebuild artifacts.
+
+But here is a problem: If your system is distributed and [each microservice is
+building a different artifact](@./microservices-artifact-input-state.md), where
+is the source of truth?
+
+Previously, I mentioned that microservices could keep an state in order to
+produce the artifact. That could be the source of truth for that microservice,
+as long as it doesn't delete old data -- in which case, how would you rebuild
+old artifacts if you can't return the state to an old... state?
+
+Another solution is to make the insertion microservice (the one that captures
+data from an external source) to build this source of truth; in case of the
+need to rebuild the data, you can just add an API in that microservice for it
+to republish data related to a certain object, which will go down the pipeline
+and every microservice will rebuild their artifacts.
+
+And, finally, if you build an event source pipeline correctly, you can build a
+single service that will listed to _every_ event and keep a global event
+source, which you can again expose an API to replay all events of an object.
+
+{% note() %}
+.. although I have a feeling that certain events should be changed; for example,
+if you make the event source replay everything related to an invoice -- in
+order to reproduce the complete invoice artifact -- you may have to replay a
+"create user" event, which won't make sense 'cause the object already exists,
+and it shouldn't create a new user with the same information.
+
+Either that, or you could make the invoice service request the costumer
+service the data if it doesn't have it already.
+{% end %}
+
+Anyway, one recommendation that I have is to always build something that can
+keep track of your data, in case you need to rebuild your artifacts and your
+state removes old data (which is perfectly normal, I must add).

content/code/microservices-source-of-truth.pt.md

@@ -0,0 +1,70 @@
++++
+title = "Microserviços: Onde Fica a Fonte da Verdade?"
+date = 2020-02-17
+
+[taxonomies]
+tags = ["microserviços", "fonte da verdade", "estado"]
++++
+
+Quando estamos falando de um sistema, existe um ponto que precisamos discutir
+que é onde a "fonte da verdade" está. Em monolitos, a fonte da verdade está no
+armazenamento dos dados em si. Mas onde é que essa fonte fica em um sistema
+que é composto de múltiplas partes?
+
+<!-- more -->
+
+Só para ficar claro aqui: O que eu quero dizer com "fonte da verdade" é
+qualquer coisa que você possa usar para verificar se o sistema está produzindo
+os valores corretos. Por exemplo, em um pipeline que conta quanto foi
+transferido de cada usuário em uma CDN, a fonte da verdade podem ser os logs
+(você pode ler os logs e verificar se o sistema responsável por somar os
+valores está correto); num site de e-commerce, podemos assumir que a fonta da
+verdade é a lista de itens comprados em cada pedido para receita total (se
+você somar todas as quantidades e seus preços de venda, você vai ter a receita
+total de volta).
+
+Um fator importante da fonte da verdade e que você pode usar tanto para
+verificar se os serviços estão corretos quanto reaplicar o conteúdo de volta
+no sistema para que artefatos sejam reconstruídos.
+
+Mas existe um problema: Se o sistema é distribuído e [cada microserviço cria
+um artefato diferente](@./microservices-artifact-input-state.pt.md), onde é
+que fica a fonte da verdade?
+
+Anteriormente, eu mencionei que microserviços podem manter um estado para
+produzir o artefato. Essa pode ser a fonte da verdade para o microserviço,
+desde que o mesmo não apague dados antigos -- nesse caso, como é que artefatos
+antigos seriam reconstruídos se você não pode retornar o estado a um estado
+anterior?
+
+Outra solução é alterar o microserviço de importação de dados (aquele que
+captura dados de uma fonte externa) para construir a fonte da verdade; havendo
+a necessidade de reconstruir artefatos, você pode simplesmente adicionar uma
+API nesse microserviço para que ele republique os dados relacionados com um
+determinado objeto, que irão percorrer o pipeline e cada microserviço irá
+reconstruir seus artefatos.
+
+E, finalmente, se você construir um pipeline de event source corretamente,
+você pode criar um serviço que irá escutar _todos_ os eventos e manter um
+event source global, que você pode, novamente, expor uma API para reenviar os
+eventos relacionados com um objeto.
+
+{% note() %}
+... embora eu tenha a sensação que certos eventos precisariam ser alterados;
+por exemplo, se você mandar o event source reenviar os eventos relacionados
+com um epdido -- para que seja recriado o artefato desse pedido -- você pode
+ter que reaplicar um evento de "criar usuário", que não vai fazer sentido
+porque o objeto já existe e não deve ser criado mais um usuário com as mesmas
+informações.
+
+Ou isso ou você vai ter que fazer com que o serviço de pedidos peça os dados
+do cliente se ele já não tiver os mesmos.
+{% end %}
+
+De qualquer forma, uma recomendação que eu tenho é sempre construir alguma
+coisa que possa guardar os seus dados, de forma que você possa reconstruir
+seus artefatos novamente e os serviços apagam dados antigos (que é
+perfeitamente normal, diga-se de passagem).
+
+<!-- vim:spelllang=pt 
+-->