Możliwe jest zarządzanie użytkownikami/tożsamościami w magazynie danych, który wykazuje ostateczną spójność?

Question

Czy można tworzyć/przechowywać konta użytkowników w magazynie danych, który wykazuje ostateczną spójność?

Wydaje się niemożliwe, aby zarządzać tworzeniem kont bez zbędnej złożoności architektury, aby uniknąć sytuacji, w których mogą występować dwa konta o tym samym identyfikatorze UID (np. Adres e-mail)?

Czy użytkownicy ewentualnych magazynów konsystencji używają oddzielnego spójnego DB jako magazynu tożsamości, czy też istnieją rozwiązania/wzorce, które powinienem zbadać?

Dzięki z góry,

Jamie

Answer 1

To jest możliwe do zarządzania użytku w końcu konsekwentne magazynu danych. Robimy to. Działa zgodnie z następującymi założeniami:

1. Konflikty nie powinny się zdarzać, a kiedy to robią, istnieje wyraźna ścieżka rozwiązywania konfliktów. Jeśli identyfikator konta to adres e-mail osoby, to jeśli dwie osobne osoby próbują zarejestrować się pod tym samym adresem e-mail, jest tutaj większy problem. W tym przypadku robimy to, blokując oba nowe konta zaraz po wykryciu konfliktu i wysyłając wiadomość e-mail na adres będący w konflikcie, wyjaśniając użytkownikowi, że istnieje problem (możliwe oszustwo). Możesz poprosić użytkownika o zresetowanie konta lub poproszenie go o skontaktowanie się z pomocą techniczną.

2. Powtórzony dostęp tego samego użytkownika w terminie, w którym dane są niespójne, powoduje przejście do tej samej repliki. Na przykład, jeśli osoba, która właśnie się zarejestrowała, a następne żądanie jest loginem, musisz zweryfikować to logowanie w replice danych, w której istnieją nowe dane rejestracyjne. Jeśli więc ostateczna spójność wynika z wielu centrów danych w różnych lokalizacjach geograficznych i w normalnych warunkach żądanie jest kierowane do najbliższego centrum danych geograficznie, wszystko jest w porządku.

Istnieją pewne przypadki brzegowe, takie jak, jeśli użytkownik zarejestrowany na jednym centrum danych, a następnie, że centrum rozbił, a teraz użytkownik nie może się zalogować mimo że wciąż można zobaczyć aplikację - podawane z innego centrum danych . Możesz obliczyć oczekiwaną częstotliwość tego przypadku na podstawie liczby nowych użytkowników dziennie i przeciętnego przestoju centrum danych. Następnie zdecyduj, czy warto martwić się o jednego użytkownika w (milion/miliard/jakikolwiek twój numer) mającego problem i prawdopodobnie kontaktującego się ze wsparciem. Niedawno stanąłem przed tą samą decyzją i zdecydowałem, że z perspektywy kosztów i korzyści odpowiedź brzmi "nie".