Matt Reiferson

hi @thekingofworld, sorry for the delay, I'll try to find some time this week to take a closer look. We do know that at larger scale there are performance issues...

Thanks for continuing to push this forward @thekingofworld. The approach here will now be much more costly on the write (registration) side, because each write will now have to walk...

seems useful, ultimately related to conversation in #853

SGTM, I suspect this one is going to be a bit tricky. > Should each topic (and/or channel) be closed as they are drained or should they only be closed...

Also love that this and #1300 are labeled `chore` 😂

Got it. In that case, simplest way might be to to proactively send a tombstone to `nsqlookupd` (to avoid new clients discovering that node) but not closing (which may force...

Excited to see all this! I should have some time in the next few days to review.

This reminds me a bit of the issues discussed in https://segment.com/blog/the-10m-engineering-problem/ These are indeed problems worth solving, but why does this need to be built into `nsqd`? I find it...

> Because messages are push based, only nsqd has the ability to implement this in a way that fulfills the realtime promise of nsq. A client "could" make zone aware...

Given this issue, and #1078 and #980, feels like we should keep this one open to be the catch all for discussion / tracking for making NSQ more "cloud native"...