Consistency Models & CAP
What actually happens when the network splits.
The CAP theorem says that when the network between your database nodes breaks — a partition — you must choose: stay consistent (everyone sees the same data) or stay available (everyone gets an answer). You cannot have both while the nodes cannot talk.
The animation makes the choice physical. Two datacenter nodes are connected by a cable, and scissors cut it. On the CP path (consistency first), watch one node refuse requests behind a "sorry, down" shield — it would rather give no answer than a possibly-wrong one. On the AP path (availability first), both nodes keep answering, but their values visibly diverge — two users see different data. When the cable heals, watch the values animate merging back together: that is eventual consistency, the promise that replicas converge once they can talk again.
The interview insight is that this is a per-feature choice, not one global switch. A feed or a view count can tolerate the AP path's staleness; inventory, seat bookings, and money cannot — they need the CP behavior. Saying "bookings need strong consistency, browsing can be eventually consistent" in your requirements, in the first five minutes, is exactly the signal interviewers listen for.