diff --git a/content/code/microservices-source-of-truth.md b/content/code/microservices-source-of-truth.md new file mode 100644 index 0000000..530f581 --- /dev/null +++ b/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? + + + +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). diff --git a/content/code/microservices-source-of-truth.pt.md b/content/code/microservices-source-of-truth.pt.md new file mode 100644 index 0000000..af691ed --- /dev/null +++ b/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? + + + +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). + + diff --git a/content/reviews/books/rin-tin-tin-a-vida-e-a-lenda.pt.md b/content/reviews/books/rin-tin-tin-a-vida-e-a-lenda.pt.md index 66408e8..bdc718a 100644 --- a/content/reviews/books/rin-tin-tin-a-vida-e-a-lenda.pt.md +++ b/content/reviews/books/rin-tin-tin-a-vida-e-a-lenda.pt.md @@ -6,7 +6,7 @@ date = 2016-07-04 tags = ["books", "susan orlean", "biografia", "rin tin tin"] +++ -[Resumo GoodReads](): +[Resumo GoodReads](https://www.goodreads.com/book/show/18396199-rin-tin-tin): Ele achava que o cão era imortal. Assim começa a vasta, poderosa e comovente narrativa de Susan Orlean sobre a jornada de Rin Tin Tin – de sobrevivente órfão a astro do cinema e ícone internacional do showbiz. Suzan, redatora da diff --git a/content/reviews/books/the-complete-collection.md b/content/reviews/books/the-complete-collection.md index 55135f8..b12568d 100644 --- a/content/reviews/books/the-complete-collection.md +++ b/content/reviews/books/the-complete-collection.md @@ -6,7 +6,7 @@ date = 2014-11-29 tags = ["books", "h.p. lovecraft", "reviews", "horror"] +++ -[GoodReads Summary](): +[GoodReads Summary](https://www.goodreads.com/book/show/50029451-h-p-lovecraft): The weird fiction short stories of H.P. Lovecraft from 1917-1935. Excludes collaborations.