Hacker News Reader

Comment by thaumaturgy | Hacker News Reader

There are a couple of options for making your front-end redundant: round-robin DNS, or a CDN.

In either case, it still leaves you with a single point of failure in the backend. Your best bet there is probably to get a second VPS through a completely different provider -- and figure that you'll never lose both at the same time -- and then set up replication between the two databases, along with a monitoring process to switch the front-end to the backup database in the event that the primary becomes unreachable.

View on HN

Round Robin DNS can play havoc with e-commerce software that was built on dumb assumptions about session handling. The usual symptom is carts vanishing and reappearing semi-randomly. If I'm going cheap a webserver set up as a reverse proxy can manage a large number of sessions spread out over multiple application servers. It's not as good as dedicated network hardware, but it's better than round-robin dns.

Ugh, I didn't know that about session handling.

As a tangent: guys, current ecommerce packages really, really suck. I've had a couple of ecommerce jobs recently, and for one client in particular, had to evaluate most of the field of both free and commercial offerings. They're almost uniformly horrible. Is there anybody willing to take a crack at doing it better?

I suggested round-robin DNS over a reverse proxy because reverse proxies (and similar services, like OpenBGPd) still have a single point of failure in the front-end. No matter what you do, it can still go down, and then all that back-end redundancy does squat.

The fix in most cases is having a shared session-store (memchached usually) that the front-end instances share. It's not that painful to retrofit it if you know the software.

http://spreecommerce.com is the best I could find, I've recently been customizing it for a client.

Thanks for the link! Looks like I finally have an excuse to learn Ruby.

There are DNS failover providers that will host your DNS records and provide monitoring and automatic failover between IPs. This takes propagation time out of the equation.

This unfortunately doesn't resolve problems with bad caching behavior -- not all internet service providers, including the big ones, are observing TTL or sane caching.

I think you're still better off solving the problem without relying on TTL or DNS caching behavior that you don't have control over.

Could you please list a couple or recommend one out of experience? Thank you.

Reply on news.ycombinator.com