Brad from Census (https://www.getcensus.com https://www.getcensus.com) here - I wanted to add some technical detail for the HN crowd. On its face, a Census wor

Brad from Census (https://www.getcensus.com https://www.getcensus.com) here - I wanted to add some technical detail for the HN crowd. On its face, a Census workflow is a simple "program" that our users author in a point-and-click manner – read some data from System A and broadcast it to Systems B, C, and D. But to "compile" that program, Census has to determine: - Which APIs to use (bulk, streaming, etc) - The schema of each destination (which can change out from underneath us at run time!) - The semantics of reads and writes from each system (atomicity, isolation, how roll back if a write fails) - How to map data with high-fidelity across strongly-, weakly-, and dynamically-typed data stores That's just compilation – then we need to execute that compiled plan and move massive amounts of data with low latency and high throughput, all while handling byzantine failures in source and destination systems and automatically rolling back, recovering, or helping users "debug" their workflows when things go wrong. There's a lot of depth to this (and we haven't "solved" it by any means) - happy to answer questions here or at brad@getcensus.com if you have them!