Hello, I have a Platform team who has created a Ka...
# platform-culture
Hello, I have a Platform team who has created a Kafka producer/consumer service following the Transactional Outbox Pattern. The outbox tables live with in the databases owned by the service teams. I had hoped / expected that the service teams would own this table and outbox relay since it is a per service database setup in databases they own. We created documentation expecting this. I am getting pushback because some Kafka expertise is required for maintenance. We are open to supporting them with knowledge/consulting but they are pushing back for my Platform team to own them. I am reluctant because I am not sure how scalable it is for my team to own X outbox tables that live in databases owned by the service teams. Anyone else ever hit this problem or similar issue?
This happens all the time. Unfortunately, it sounds like expectations weren't established before building this service for the dev team. The good news is you're not stuck with everything...yet. I would use this as an opportunity to clarify and tease apart the responsibilities between your platform and dev team. Here are some thoughts that may help your conversations (these are based on a platform engineering mindset of "you build it, you run it"): • You mentioned contention around who owns the table. Dev teams usually own all data that they produce. So, the data in the table would be owned by the dev teams. If the table schema needs changed, I think this would fall under maintenance of the reusable service (see next note) • Platform teams usually maintain reusable libraries/frameworks/services. This means feature updates, bug fixes, security updates. • Some engineering orgs have shared services that are a single instance of production resources while some will require each dev team to stand up an instance of a reusable service. It's unclear where your org stands on this, but I believe it's within the platform team's responsibility to (at minimum) figure out how to perform upgrades on this service • Deciding who should perform these upgrades/updates requires a little more knowledge and context. I would do some critical thinking and work with the dev team to figure out a strategy that works for both.