# nsq

NSQ is a realtime distributed messaging platform.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Z Proxy: Bitly's Independent Link-Redirect Fallback

DevFeed: [Z Proxy: Bitly's Independent Link-Redirect Fallback](<https://devfeed.tech/articles/z-proxy-19703.md>)

Original publisher: [Read original article](<https://word.bitly.com/post/62914279559>)

Author: Wordbitly

Published: 2013-10-02T17:47:22Z

Content type: article

Language: en

Sources: [Bitly](<https://devfeed.tech/sources/bitly.md>)

Topics: [Availability](<https://devfeed.tech/topics/availability.md>), [Amazon S3](<https://devfeed.tech/topics/amazon-s3.md>), [Go Language](<https://devfeed.tech/topics/go-language.md>), [Amazon EC2](<https://devfeed.tech/topics/amazon-ec2.md>), [nsq](<https://devfeed.tech/topics/nsq.md>)

Tags: [availability](<https://devfeed.tech/tags/availability.md>), [ec2](<https://devfeed.tech/tags/ec2.md>), [go](<https://devfeed.tech/tags/go.md>), [nsq](<https://devfeed.tech/tags/nsq.md>), [s3](<https://devfeed.tech/tags/s3.md>)

### AI overview

Bitly describes Z Proxy, a Go application designed to keep short-link redirects available independently of its main infrastructure. It stores link mappings in S3, uses NSQ to populate them, runs on EC2, and caches S3 lookups locally with memcached.

### Source excerpt

Here is a tale of how we leverage redundant datacenters, redundant code, and multi-tiered fallbacks in the quest for uptime. But Why? High availability is important for any site operating at scale, but at bitly it is particularly important; people expect bitly links to work, no matter what. We have enterprise customers who rely on them for key metrics, users who share them on social networks, and websites with custom short domains that trust us to serve requests with their name on them. A bitly link not working in any of these scenarios would make our users look bad, so it is something we take very seriously. No matter how redundant, distributed, and fault tolerant your main infrastructure is, things can always go wrong. Recently Google Apps and Search, probably the most distributed infrastructure in existence, went down. There are unknowns everywhere, and ultimately you have to plan for any part of your infrastructure breaking for unknown reasons. Under failure, a distributed system should degrade gracefully, not suddenly. This is why we created Z Proxy. So What is Z Proxy? Z Proxy is an application that serves decodes (this is what we call redirecting from a short bitly link to its long URL, and what happens every time you click on a bitly link) without relying on any other part of the bitly infrastructure. This means that it does not use our primary database of urls, or any of our other servers, to do lookups. So how does it work? How it Works Z Proxy is essentially a self contained wrapper around S3, written in Go. When all of bitly is running properly, every time a link is shortened, a message is put on NSQ, which a queuereader later grabs. A queuereader then writes the short and long urls into S3 so that Z Proxy can perform lookups against S3 by short url, get the long url, and serve a 301 or 302 redirect. To the browser, nothing different happened. There are multiple host running Z Proxy in EC2. This location provides proximity to S3, high availability, and m