Redakcja
Wyobraźmy sobie, że robisz aplikację mobilną do rezerwowania wizyt u fryzjera. Zastanawiasz się nad potencjalnymi awariami, jakie mogą się w niej pojawić, poczynając od niedziałających funkcji, po problemy bezpieczeństwa.
Pewnie nie przyszłoby Ci do głowy następujące ryzyko:
IF (jeśli),
świat zostanie zaatakowany przez śmiercionośnego wirusa,
AND (logiczne „i”)
zbliżają się święta,
AND
przywódca kraju ogłosi zamknięcie fryzjerów za kilka dni,
AND
pomimo zagrożenia, ludzie muszą mieć ładne fryzury,
THEN (wtedy)
Wszyscy użytkownicy rzucą się na aplikację, w panice poszukując najbliższego terminu u fryzjera w promieniu 50km.
Takiego gwałtownego obciążenia aplikacji i architektury nie jesteśmy w stanie obsłużyć bez ponoszenia olbrzymich nakładów na infrastrukturę. Nawet zakładając, że udałoby Ci się przewidzieć taki problem, to i tak może się okazać, że gra nie jest warta świeczki. Średnie obciążenie aplikacji możemy łatwo badać i dopasować do niego nasze zasoby. Niestety nawet najmocniejsze serwery mogą klęknąć przed użytkownikami, którzy gwałtownie napierają na nie swoimi zapytaniami. I może rzeczywiście nie warto ponosić kosztów obsłużenia tego szalonego strumienia próśb o rezerwację, skoro pula terminów jest bardziej niż ograniczona. Ryzykujemy pogorszeniem opinii na temat naszego oprogramowania, ale zawsze możemy bronić się popularnymi stwierdzeniami typu:
- „Nie działa bo wiesz, jest pandemia”.
- „Co ten rząd, to ja nie wiem. Wszystkich nas wykończą”.
- „Tego nie dało się przewidzieć”, lub alternatywnie: „No przy takim ruchu to wszystko by padło”.
I jak widać po opiniach dla samej aplikacji, to ten problem nie wpłynął znacząco na negatywne oceny.
Choć ta historia się zdarzyła, a aplikacja Booksy naprawdę istnieje, to mogłoby się to przydarzyć każdemu z nas.
