5 ms·

Question: Imagine that you have a non-session-persisting load balancer in front of a cluster of web servers (n >= 3). Since this load balancer doesn't direct r

by lowglow 15y ago

Question: Imagine that you have a non-session-persisting load balancer in front of a cluster of web servers (n >= 3). Since this load balancer doesn't direct requests in any persistent fashion, a user making subsequent requests may be directed to any of the servers available in the cluster in a non-deterministic manner. In your application, you need to handle image uploads from users, and as soon as the upload is finished, you need to show the user their uploaded image. This creates a problem for you because after an upload, the load balancer may direct the user to a web server which does not have the users recently uploaded image resulting in a 404 Not Found for the image request and a poor user experience. In the current system, an rsync process runs every 5 minutes and copies uploaded images around to each server so that every server has every file, eventually. This isn't a very optimal solution because users may not see their uploaded images for up to 5 minutes depending on which server they are connecting to for any given request and it forces every server to have a copy of every image uploaded, which may not be the most scalable solution. Assuming you could not modify the load balancer, how would you redesign or fix this system so that files are uploaded in a way that it doesn't matter which server in a cluster a user connects to in order to be able to satisfy a request for the file? There are many ways to solve this problem. Please describe one or more ways and discuss the pros and cons of your solution(s). If your solution is very simple (not a bad thing), consider offering a couple alternate solutions so we have a strong understanding of how you evaluate and approach problems. - My Response: Basically that this was poor architecture and didn't make sense. They shouldn't be using their web servers as a file store. They didn't like that.

bmelton 15y ago
No offense intended, but I wouldn't have liked that answer either, especially as it isn't an answer to the question posed. It might well have been a hypothetical problem they've had in the past or that they've heard of, or it might have even been that their application requirements evolved into the use case above. Not answering the question doesn't indicate that you can solve the problem. Right or wrong, businesses arrive at scenarios like this often due to circumstances outside their control. Either way, I like it as an interview question, as it would effectively filter out people who are either not clever enough to solve it or not motivated enough. When I hire, one of the best things I can hope to find in an potential employee is a 'can-do' attitude. While that might sound cliche, you can hire pretty much any smart person to point out the problems you have. It's much more difficult to hire somebody who can both identify those problems and come up with potential solutions and is capable of fixing them.
- lowglow 15y ago
  I'd rather someone tell me that the problem is flawed and offer me another alternative to avoid future problems -- that would be experience talking. I'd rather have someone FIX problems and not just patch a system continuously hobbling down the wrong path. I'd like not be too far down the rabbit hole and figure out we need a major architecture overhaul. More research and planning from the start, saves time and money in the end.
  - caw 15y ago
    Agreed. But this isn't even a solution you can't implement for legacy reasons. At any point you can do this, and you can probably do it live by taking it out of the load balancer equation one at a time. In this case, centralizing storage makes sense. Pros: less stuff to manage, no more rsyncs, immediate feedback on all servers. Save money by only needing to buy 1/n amount of space (assuming the space required is significant) because you're only maintaining X GB centrally versus X GB * n servers. Cons: Money up front, increased latency to fetch data, but you're already waiting up to 5 minutes.
maushu 15y ago
I would first try and add a new server just as file store behind those web servers, the web servers would upload the file to this server and proxy requests to it (using a cache on the web server to speed up repeated requests). In case we can't add any new servers, I would save the initial web server address (ex: lan ip) where the file was uploaded, to the database (we are using a common database, right?) and when the image is requested (and doesn't exist on the current web server), reverse proxy from the initial web server. Those architectures are a little hack 'n' slash, but you got to do what you got to do.
devs1010 15y ago
change the rsync to run every second... stupid question, stupid answer

by lowglow 15y ago

bmelton 15y ago

No offense intended, but I wouldn't have liked that answer either, especially as it isn't an answer to the question posed. It might well have been a hypothetical problem they've had in the past or that they've heard of, or it might have even been that their application requirements evolved into the use case above. Not answering the question doesn't indicate that you can solve the problem. Right or wrong, businesses arrive at scenarios like this often due to circumstances outside their control. Either way, I like it as an interview question, as it would effectively filter out people who are either not clever enough to solve it or not motivated enough. When I hire, one of the best things I can hope to find in an potential employee is a 'can-do' attitude. While that might sound cliche, you can hire pretty much any smart person to point out the problems you have. It's much more difficult to hire somebody who can both identify those problems and come up with potential solutions and is capable of fixing them.

lowglow 15y ago
I'd rather someone tell me that the problem is flawed and offer me another alternative to avoid future problems -- that would be experience talking. I'd rather have someone FIX problems and not just patch a system continuously hobbling down the wrong path. I'd like not be too far down the rabbit hole and figure out we need a major architecture overhaul. More research and planning from the start, saves time and money in the end.
- caw 15y ago
  Agreed. But this isn't even a solution you can't implement for legacy reasons. At any point you can do this, and you can probably do it live by taking it out of the load balancer equation one at a time. In this case, centralizing storage makes sense. Pros: less stuff to manage, no more rsyncs, immediate feedback on all servers. Save money by only needing to buy 1/n amount of space (assuming the space required is significant) because you're only maintaining X GB centrally versus X GB * n servers. Cons: Money up front, increased latency to fetch data, but you're already waiting up to 5 minutes.

maushu 15y ago

I would first try and add a new server just as file store behind those web servers, the web servers would upload the file to this server and proxy requests to it (using a cache on the web server to speed up repeated requests). In case we can't add any new servers, I would save the initial web server address (ex: lan ip) where the file was uploaded, to the database (we are using a common database, right?) and when the image is requested (and doesn't exist on the current web server), reverse proxy from the initial web server. Those architectures are a little hack 'n' slash, but you got to do what you got to do.

devs1010 15y ago

change the rsync to run every second... stupid question, stupid answer