Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Where do the keys get backed up to? If nowhere: If the key system fails, do you just accept the loss of _all_ of your customer data? If somewhere: by what mechanism do you delete the key in a backup?


The keys dataset is going to be much smaller than everything else, and possibly immutable per customer. This in principle makes it much simpler and cheaper to handle, so it's easy to imagine how---depending on the scales and technologies involved---one could isolate it and achieve the desired redundancies and retention periods in ways that would be impractical with the full customer dataset.


That’s a long way to say “it’s definitely possible but I haven’t architected a sane solution yet.”


I find this comment rather baffling. Can you really not see what I'm talking about without having a concrete (and likely completely irrelevant to 23andMe's requirements) example spelled out for you in detail?


You didn’t even give vague details, let alone you giving a concrete example in detail. I asked a question and your previous comment answer boils down to basically, “it’s totally possible.”

My theory is that you’re making a concession somewhere in the backups to a separate keyring system. Either there is no cold backup, or you don’t do cold backups at all, or your cold backup is actually semi-warm and needs to be hooked up to a system intermittently to be reconciled against production (in which case, the backups need backups to protect against a failure on the reconciler system.) The onus is on the answerer to tell me how they would avoid one of those concessions. Respectfully, anything else/less is just fluff like, “it’s totally possible.”


The whole point of isolating the keys dataset is that you can reason about it differently. You frame these "concessions" as dealbreakers, but I don't think that's supported. Can you explain why this dataset would need cold snapshots retained past a period users would accept as a delay for guaranteed account deletion---say, two weeks? Replication already has you covered on acts of god, so we're worried about things like bad code pushes, "hackers", and so on.


> so we're worried about things like bad code pushes, "hackers", and so on.

I'm confused. Are you saying those are small concerns? Because I'm saying the backup mechanism for the keys surely need to be resilient to all of those.


No, they aren't small concerns, but you haven't shown that extended retention of cold snapshots (>2 weeks, to use my previously stated example) is necessary to satisfactorily mitigate them. What is the argument for needing a significantly longer retention period?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: