anchor.diff:  *Figure 1. The configuration file in LDS; a developer will open a PR adding a new line, the rest will be taken care of.*
   ====
   
  -Upon merging the PR, our project will provision the whole configuration to Kafka Connect, ensures the snapshot is executed, metrics and presents and etc; We've done the same thing for the Outbox pattern and I talk a little bit more about it in this https://twitter.com/renatomefi/status/1185098904745992197[tweet thread].
  +Upon merging the PR, our project will provision the whole configuration to Kafka Connect, ensures the snapshot is executed, metrics and presents and etc; We've done the same thing for the outbox pattern and I talk a little bit more about it in this https://twitter.com/renatomefi/status/1185098904745992197[tweet thread].
   
   Self-servicing the teams was a great way to remove resistance for adoption, no Jira tickets were necessary, no advanced ops knowledge or anything else to get it running. The other factors I consider to have contributed to Debezium's success in our platform is its reliability and straight forward value perception, in those 2 years we never had major outages or critical problems of any kind!
   
  
positive.code: 
  When I think of the Kafka and Debezium ecosystem, the next steps I consider important are the ones which will make it more accessible. Although there's a lot of content and examples online, there's still a big gap between reading those and getting to a production ready implementation.
  
  What I mean by that is abstracting the individual pieces away and giving them more meaning. The Outbox pattern is a good example, it was not natural for people to think of CDC and know that it was such a good match to it, there are plenty of more use cases to be explored in this ecosystem.
  
  What if you could have everything out-of-the-box? An outbox implementation in your favorite framework, which knows how to integrate with the ORM, handle the transaction part, then, how to shape the messages and events? How to adopt the schema for it and how an evolution of it looks like. After that, getting closer to the consumer implementation, how can I handle the messages idempotently, respect the semantics, do retries and project them to a database if need be?
  
  
negative.code: * _Avoiding distributed transactions_ as much as we can, it's scary and we should be scared about it too!
  * _Manageable effort_; how can we "easily" get 30+ engineers to adopt a solution for this problem? At the same time, how can you ensure the implementation guarantees among every service and team?
  
  We realized that the https://microservices.io/patterns/data/transactional-outbox.html[outbox pattern] would help us meet those requirements: applications would publish events via an outbox table, which gets written to as part of business transactions in the database.
  
  As with the strangler pattern, we wanted to resort to an architecture component, something the teams could self-service. At first, we were exploring a home-grown solution which would look for the outbox tables among every service and publish the messages. The problem with this approach would be the polling databases problem, although in this case this is less harmful as we don't need to look for updates or deletes.
  
  