# Best Practice in using Kafka Connect/CDC on a normalized database while still exposing a nice entity API

**URL:** <https://forum.confluent.io/t/best-practice-in-using-kafka-connect-cdc-on-a-normalized-database-while-still-exposing-a-nice-entity-api/1280>\
**Category:** Architecture and Design\
**Created:** [23 March 2021 17:26 UTC](https://forum.confluent.io/t/best-practice-in-using-kafka-connect-cdc-on-a-normalized-database-while-still-exposing-a-nice-entity-api/1280 "2021-03-23T17:26:51Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![lwiddershoven](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.confluent.io/lwiddershoven/32/650_2.png) [@lwiddershoven](https://forum.confluent.io/u/lwiddershoven)\
**Post date:** [23 March 2021 17:26 UTC](https://forum.confluent.io/t/best-practice-in-using-kafka-connect-cdc-on-a-normalized-database-while-still-exposing-a-nice-entity-api/1280/1 "2021-03-23T17:26:51Z")

</div>

As inspired by the Kafka Connect JDBC primary key talk on Youtube. [Kafka Connect JDBC sink deep-dive: Working with Primary Keys - YouTube](https://www.youtube.com/watch?v=ABOJGB5G35k&t=18s)

Hi Robin, thanks for the video. I love the extra details!

I have a question that is not so much about CDC, but on how to share the normalised data of a database as a nice single entity (document) with the organisation.

As an example I imagine an order, which refers to an address and a list of order items each in their own table.

The order, the address and the order items are all mutable - the customer can change it all and as a result I want to send to my clients a single Kafka document with everything in it.

How would you go about this? Both in combining the 3 change streams into a single new stream regardless of what changed, and only sharing the nice API with the organisation?  
In short, I’d love a video with a special focus on sharing a maintainable API with the rest of the organisation