[anirudhrx]

I was just about to post this :)

Depending on the request context (typically a set of headers), a request will end up going to one of baseline service A or A’, but never both. Depending on the scenario being tested, you can choose to isolate additional stateful components. In the case of testing a change to the database itself (DDL, etc), you’re right in that the database must be isolated so that A’ does not talk to the same shared database as A. So, as you pointed out, typically this would involve using a resource plugin (https://docs.signadot.com/docs/using-resources-with-sandboxe...) to set up that new database shard (or table, or schema) that is isolated as part of the test sandbox environment, and then linking A’ to talk to that isolated instance instead.

Kafka is on our roadmap next! We're actually working right now on making custom resource plugins easy to write, because invariably with databases, there's a data seeding step that's pretty custom for users. Right now, for building a custom plugin, aside from writing the logic in the provision / deprovision scripts (for ex. https://github.com/signadot/plugins/tree/main/src/mariadb), there's a bit of docker image building and helm packaging needed that we're hoping to simplify.

[volkk]

> a request will end up going to one of baseline service A or A’, but never both

that's interesting, i totally didn't gleam that. so X percentage of users are getting a potentially bugged experience? is this kind of like a more robust feature flagging tool? i.e "rollout this thing to 1% of people for X time, and then roll it back to control"

and if so, if you have 200 engineers all testing all sorts of stuff on prod users/data, the chances of buggy experience for small amounts of people increases? am i understanding that correctly?

[anirudhrx]

Ah, the primary use-case here is for developers to test microservices as changes are made to them - so one would typically be running this setup in pre-production / staging only and no prod user data would be involved. I would think of it as a way to run integration / e2e tests for each commit or pull request. Running these tests in the high fidelity test environment constructed this way reduces the bottlenecks on staging environments, and bugs are discovered / addressed sooner.

[volkk]

AH! derp. thank you that makes total sense :) -- seemingly awesome tool, will certainly look into this. thanks for the quick responses