For me personally, the ability to write custom authentication plugins for HTTPie is the reason I use it. For my use case I wrote a simple AWS Sigv4 [0] plugin to simplify calling AWS API Gateway endpoints during development/debugging.
I'm in the same boat - looking to consolidate a few smaller data pipelines that have organically grown over the years into a single pipeline and taking the opportunity to try and get the org to rethink how we emit events in various parts of the stack. As teams operate fairly independently, we need something that enables a flexible data structure whilst still enabling the ability to join data on common well-defined fields.
The current path we are going down is looking at using a 'nested' JSON structure that enables sub-processes in the various systems to inherit values from the parent. Something similar to:
The structure itself will be documented using JSONSchema and hopefully we will be able to verify the validity of events as they are processed, though this might be too expensive to do in high volume scenarios.
The goal is to then build a low latency router that takes in routing policies to forward subsets of events to further data pipelines. The policies themselves will be defined using some kind of DSL (possibly using JSONPath?).
As a whole, this seems to be a fairly common problem[0] that other companies are trying to solve, but a lot of the low level details are not spoken about. One thing that does seem to be a common component to a service like this is Apache Flink.[1]
It looks like the compiled binary just gets exec'd by the Lambda function and listens on a TCP port (specified by the environment variable _LAMBDA_SERVER_PORT) which accepts RPC calls to execute the handler using net/rpc.
[0] https://github.com/docker-slim/docker-slim#debugging-minifie...