Improving Information Architecture for AWS ElastiCache

AWS ElastiCache had a problem. Over several years and more reassigned writers, the docs site had inherited a situation of too many pages. By the thousands. Even worse, the pages were either identical and redundant, or didn’t show differences in products when the user needed to know.

The pages were in two different instances of the same core XML, which both had to built and published for the smallest change to go live. One site was for ElastiCache with the 3rd-party engine Redis, and the other site for the 3rd-party engine Memcached. Updating these separated sites could be complex and difficult. Changing a link on one page could break a build, fixing that link by renaming it could break another link, and so on. Doc builds were taking quite long, and frequently failing.

Worst of all, external developers and users who depended on ElastiCache could have a hard time searching for what they needed. What they would find might work for one engine but not the other. So bad SEO as well.

Action: while continuing to update the separate sites as they came in, created a separate Git branch where I was gradually collapsing both sites into one. Also initiated a discussion about eventually doing this.

Several months later, the opportunity came: ElastiCache was launching an open-source fork for their own engine, Valkey. I made the case: rather than confusing our customers and our SEO further, finally make one site for ElastiCache with all 3 engines. Only note the differences when the user would need to know.

The operation was a grand success, with immediate benefits of a 9% reduction in NPP (Negative Participation Profile), as rated by customer feedback on each page.