Load balancing with affinity is commonly employed when preserving a user's session state with a specific backend node is important. This approach ensures that once a user’s initial request is served by a particular server, subsequent requests from that same user continue to be directed to the same server. The result is lower latency and improved performance because the server already holds any relevant session-related data (e.g., authentication tokens, in-memory cached results, or transient state information).
A) suggests that certain premium users always go to the same high-performance server. This is a form of affinity, but it ignores server load and could result in overburdening a single machine, causing performance degradation and potential downtime for premium users.
B) describes routing users to their closest server but dynamically switching if load becomes excessive. While this is an effective load balancing strategy, it isn’t a pure affinity scenario. It's more about adaptive routing that optimizes for performance rather than enforcing a strong user-to-server binding.
C) is ideal. A financial trading platform must maintain session state for the duration of a user’s trading session. By using session affinity, the platform ensures low latency and stable transactional state. At the same time, the load balancer can still be configured to distribute new sessions evenly across servers, mitigating the risk of overloading any single node. Established sessions remain on the same server for consistency, while new sessions are started on less busy servers.
D) describes a global load balancing scenario, which is effective for availability and even distribution of load. However, it does not address session affinity, since requests are simply distributed across multiple servers based on predefined balancing algorithms.