4 ms·
Late to the party, but someone at the office shared https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43146.pdf https://storage.googleapis.co
by giaour 7y ago
Late to the party, but someone at the office shared https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43146.pdf https://storage.googleapis.com/pub-tools-public-publication-... , which reminded me of this question. You're right that the system consuming data from the lake is taking on debt by building a system around what is by design an unstable signal. The consumer is also attaching technical debt (in the form of visibility debt) to the producer, since changes to the data fed into the lake now have an undeclared consumer that may break if the data format or cadence changes in ways that seem innocuous to the data originator. At the major tech company where I work, this would result in someone on the team responsible for the data originator getting paged.
I would recommend reading the paper linked to above and sharing it with teams that are taking the approach you describe.
- kyllo 7y agoThanks for the link, this is a good formal description of the one main problem I'm seeing with this type of architecture (undeclared consumers) as well as several others I hadn't thought of.