Disrupting the KTV world in China

Context

We spearheaded the growth of one of the fastest growing WeChat apps for the biggest beer company in the world. AB InBev came to us to help them in designing and building the software, infrastructure and team to grow the Yedian venture.

In addition to this, we helped them to scale and accelerate their pace of innovation through strategic and technical best practices. In response to their growth rate, we also provided them with the technical components they need to grow their userbase beyond WeChat.

Metrics

• 180,000 registered users

• 12,000 active users per week

Key Technologies

• Node.js
• Kong
• Ansible
• Vue.js
• WeChat API

Key Concept

Gateway and Auth-service

The Problem

• Yedian had built a quick prototype with plain PHP, which works, but was very hard to scale or extend.
• They were extending both the product and the team to take on more opportunities through new channels and markets
• They wanted to have a smooth transition to the new system

The Ultimate Goal

To have the system completely rebuilt with better tech and in a extensible structure that the team can improve constantly

The Solution

We spent some time figuring out the final structure, which is in a micro-services style, as well as the first steps, which is that we start with a new standalone Auth service. To make that happen we needed a few things:

• The Gateway:
  1. We needed a Gateway to manage the services. It needs to proxy requests, protect APIs, and authenticate users etc
  2. We chose Kong which is well known and easier to maintain than custom solutions
  3. However out of the box it doesn’t do user authentication and ACL etc. So we needed to build an Auth service and integrate it with Kong, with custom plugins written in Lua
• Auth Service:
  1. We use Node.js to build a standalone service which handles user login, user type, and user role
  2. It has public API for users to login and a private API for Gateway and the other services to integrate with
  3. Gateway uses the user type and role to do ACL on a API level, say which type of user can use which API or which service etc
  4. For model level ACL it’s still the job of individual services
  5. For authenticated requests Gateway would pass the user info with custom headers, and for more user info the other services would use the private APIs from the Auth service

It worked and people were able to continue from there, to build other services and plug-n-play easily