anchor.diff:  * _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 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.
  +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.
   
  
positive.code: 
  When I classify Debezium within our product, I say it is an architectural component, the idea behind this is to position it as a platform/infrastructure concern, in a way that it can reach multiple parts of the stack and services. I consider this abstraction of Debezium one of the key success factors it had in its adoption and growth within our platform, let me explain this better!
  
  Our first use case is likely to be one of the most common ones for CDC, the https://martinfowler.com/bliki/StranglerFigApplication.html[Strangler pattern], which for us came before Debezium; so let me tell this part of the story first: when I joined Usabilla (later acquired by SurveyMoney), there was already an effort to move our platform to a new architecture and the Strangler pattern was already there, when the first couple of services started to grow, their primary way to bring data out of legacy was to poll the database, and needless to say, this could go very wrong! Our legacy database is a MongoDB cluster, and since I was preoccupied with the polling approach I started to dig into possibilities, I was hoping to find something like a streaming api for it, but what I ended up encountering was the database changelog, "oplog" as it's called in Mongo!
  
  It came to my mind right away: "Oh, I could write something that queries the data from the Oplog and sends it to Kafka". So I checked with our in-house Senior SRE and MongoDB expert https://twitter.com/gwkunze[Gijs Kunze] who thought it could be a good idea; as a next step I went to talk to my colleague https://twitter.com/rdohms[Rafael Dohms], and we decided to do some extra Googling, and like that, we found Debezium! It was the perfect match to our needs and better than what we could have written by ourselves!
  
  
negative.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!
  
  