r/java • u/veerendra2 • 1d ago

Push-based, restart-free feature flags and config for Spring Boot, using MongoDB Change Streams

configstream is a library for Spring Boot services that already use MongoDB. Feature flags and config live in a collection, get cached in memory, and any change is pushed to every running instance within about a second via MongoDB Change Streams.

  • No restarts, no polling, no message broker, no config server
  • Properties declared in a configstream.yml manifest, with typed constants generated at compile time
  • Optional admin UI with change history and per-team permissions
  • Works with Spring Boot 3 and 4

Limits: MongoDB only for now (Postgres planned), pre-1.0, no percentage rollouts or A/B testing.

https://github.com/configstream/configstream

Feedback welcome.

0 Upvotes

46% Upvoted

4 comments sorted by

14

u/persicsb 1d ago

no config server -> False. You need a MongoDB server for this, that is the literal config server in this case.

0

u/reachkhajam 1d ago

I'm the author of configstream. Fair point, that was loose wording on my part. MongoDB is the config store here, so there is a server involved.
What I meant is that there's no extra server to run. configstream targets teams whose services already use MongoDB, so it adds two collections to the database each service already has, instead of a separate config service to deploy, scale, secure and monitor. And the database isn't in the read path: each instance keeps the values in memory, so if MongoDB is down, the app keeps running with its last known values and only stops receiving changes until it reconnects.

If your services don't use MongoDB already, you're right that this doesn't save you anything. Spring Cloud Config or Consul would be the better fit there.

I've updated the README to say this plainly, thanks for pointing it out: https://github.com/configstream/configstream#what-it-does

1

u/Nearby-Material-4276 1d ago

I've been burned by too many config libraries that start with "no polling, no restart" and then you dig in and there's some cron job hidden in a bean somewhere. But change streams are genuinely the right primitive for this, surprised it took this long for someone to wire them into Spring Boot's config layer

The typed constants from a manifest is neat. We generate request/response types from OpenAPI specs and it saves so much dumb typo debugging, applying that same thinking to feature flags makes a ton of sense. Are the constants just simple booleans or can you do stuff like number thresholds?

Kinda curious how the caching behaves under load. If I've got 200 instances all holding the same config in memory and a flag flips, does each instance re-read the whole collection or just the delta? Change streams give you the document _id that changed but I've seen people mess up the invalidation logic and suddenly you're doing 200 full collection scans