3 ms·
I disagree that session affinity, or any affinity for that matter is a scalability anti-pattern. Why add more load on Redis or the Database if you can do it in
by caleblloyd 9y ago
I disagree that session affinity, or any affinity for that matter is a scalability anti-pattern. Why add more load on Redis or the Database if you can do it in the app server? Your just adding latency and increasing database load. Unused memory in the app server is free candy.
- jdub 9y agoThere are plenty of good reasons to avoid app server state (and thus session affinity), among them: Inefficiently imbalanced load balancing can affect performance and reliability, app server changes (service restart, reboot, scale down) will drop state causing interruptions (often user visible), etc. If you don't want unused memory on your app servers, don't provision it. :-)
- caleblloyd 9y agoThere's pros and cons to each method, as we've both pointed out. My main point is that it's not an anti-pattern, it's an architecture decision, and the pros and cons of each should be weighed when designing an app. I just finished working on a real-time collaborative document editing service and chose to use document affinity so that the app server could handle collaboration directly. It is extremely performant and I'd choose this approach again any day versus farming out to Redis/RethinkDB/etc. It persists to a database as writes come in, and performs initial load from the database. Local memory accesses are orders of magnitude faster than going over the network, and it reaps the benefits.