anchor.diff:  
   I want to take the opportunity here to mention how helpful the Debezium community was for getting me started with contributing. As I showed the intent to work on this, they were super welcoming and we had a call about it, so I quickly felt productive working on the code base
   
  -Almost immediately after the conversation I started a technical draft (which you can see https://issues.jboss.org/browse/DBZ-1169[here]) and soon after the first implementation was done. I can almost certainly say we were the first ones to run the transactional outbox pattern powered by Debezium. I was running a custom build on our platform, which then finally became the official https://debezium.io/documentation/reference/1.2/configuration/outbox-event-router.html[Outbox Event Router] you see in the Debezium docs today.
  +Almost immediately after the conversation I started a technical draft (which you can see https://issues.jboss.org/browse/DBZ-1169[here]) and soon after the first implementation was done. I can almost certainly say we were the first ones to run the transactional outbox pattern powered by Debezium. I was running a custom build on our platform, which then finally became the official https://debezium.io/documentation/reference/1.2/configuration/outbox-event-router.html[outbox event router] you see in the Debezium docs today.
   I was lucky to be there at the right time and with the right people, so thanks again to the Debezium team for helping me throughout the whole process of drafting and making it happen!
   
   Will I do more open source? Yes, but I must say most of my open source activity is "selfish", I'm developing solutions to problems I face at work but I'm happy to take the extra step and make them to the OSS world, but it also makes it seasonal. One of the advantages to that is if I'm doing something for a project, be sure I'll make it to production and likely be able to find more corner cases!
  
positive.code: *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].
  
  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!
  
  
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.
  
  