🚀 First, I generally really like the changes and how you approached the PR. I saw you started initially with recomputing on every update, and then changed that down the line 👍 It's a lot of comments, but I want to highlight generally I like the PR 🙂

❓ My main question here is why are we separating it from the partition status? Do we think it would pollute the result of the partition status call, and we want to keep it separate? That's a fair point, but I'm also not sure about it honestly. I would poll the other engineers in our team channel on it (I can do that for you so you see how we do it via slack :))

I'm also not super into adding a new endpoint /actuator/partitionHealth. It's additional endpoints for little benefit I think, and makes it harder to discover partition related things. Why can't we use /actuator/partitions/health? We can simply add a new operation in the existing actuator endpoint (BrokerAdminServiceEndpoint). If it's complicated because of how it's set up now (as a plain Endpoint), one option is migrating it to a WebEndpoint).

One thing we've been wanting to do is de-Springify the modules, and move all Spring magic into a single module (dist), or leave it in Spring specific modules (e.g. the REST API). This is to avoid complex object graphs which become hard to track (if anything can provide beans), and minimize in general the Spring magic. So one opportunity here is moving the existing BrokerAdminServiceEndpoint to the dist module, for example. There's also some possible refactoring as follow up we can do in the admin service itself from what I can see 😄 (but we can discuss that separately).

🚀 nice

Please address all comments, but I'm pre-approving because I doubt we need another review (though if you want, you can ofc request one!)