Platform Engineering Team/Data Value Stream/Data Gateway

= Data Gateway Service =

Background
The Analytics Query Service (aka AQS) exploits a pattern whereby periodic batch analytics jobs are used to maintain materialized datasets, durably persisted to facilitate low-latency access via HTTP APIs. Other use-cases of this pattern have been identified, and there is interest in constructing a platform to lower the barrier to entry, making it easier, faster, and more conducive to experimenting with new datasets. It has been suggested that on top of the (6) existing, such a platform could quickly grow by 10s of datasets in the near-term. At this scale, managing bespoke access to database(s) for an arbitrary number of internal teams would likely become problematic. Even something as mundane as a fleet-wide upgrade of native drivers could be prohibitively expensive when code owners are many, varied in resources and priorities, or worse when code becomes orphaned entirely.

One way of overcoming these concerns is to de-couple client applications from the underlying database. There are many potential benefits from this -for example- preserving the future ability to transparently migrate or redistribute datasets among clusters, or to better manage resource utilization, caching, etc. The Data Gateway service is an experimental approach to decouple clients from the underlying database, by providing a generic HTTP interface to published datasets.

The premise is simple: Candidate datasets are purpose-built, and expect results that are verbatim (or nearly so) to what is stored (including attribute naming). The Data Gateway is nothing more than thin layer wiring HTTP semantics to a database table, and returning JSON-serialized results (an array of rows containing one or more JSON objects).