Systems Design Concepts Practice Test

The main idea being tested is that CAP trade-offs can be applied per feature rather than as a single blanket setting for the whole system. Some features need strong accuracy and cannot tolerate conflicting updates, while others can prioritize availability and fast reads with some temporary inconsistency. For example, seat bookings must prevent double-booking, so strong consistency across replicas (possibly with coordination) is essential, even if it means higher latency during partitions. Product descriptions, on the other hand, can tolerate a short period where some users see an older description while updates propagate, so eventual consistency helps keep the system highly available and responsive. In practice, teams use separate services or data stores with different guarantees to fit each feature’s needs, which is exactly what the statement describes. The other options insist on one universal approach, ignore CAP relevance, or claim consistency is always required, which doesn’t reflect how real systems balance these trade-offs.