How is Insider Inc. unifying our users?

Over the last 10+ years, Insider Inc. has grown from single news site covering technology to globally renowned business and general interest news publisher seen regularly by tens of millions each month.

As part of its amazing growth trajectory, the Insider Inc. platform has expanded to include multiple stand-alone sites and apps. The company also now has a wide presence on a multitude of social platforms.

But with this plethora of platforms comes a commensurate number of complications. Each platform requires its own code base and each has its own registration process, log-in, and database. (What this means is that a user on one platform has to sign-up separately to access our content on different platforms.)

To minimize this friction, we recently moved all our users to a unified database using a single login system. Below is more about how we accomplished this important goal, including some of the key challenges we faced, and how we solved them.

Challenges

As we began to investigate how users were interacting with each social platform, we realized that each database has its own schema and that each code base has its own architecture.

Challenge 1 — Roles and Permissions

Each of our platforms and third parties we integrate with have a different set of user roles and permissions. To create a new system we needed to account for these irregularities. Another complexity we encountered is using a third party for user management.

Challenge 2 — Passwords

Passwords are not always available in the same format or encryption, and sometimes they are not available at all. And we can’t just change user passwords, nor ask users to create new ones.

Challenge 3 — User Experience

User experience should not scare users; They need to feel that nothing has changed.

Challenge 4 — Adding New Features

To add new features to user management systems, we need to add them to all codebases and modify them accordingly. Sometimes this isn’t possible.

Solution, Solutions (or no Solution)

After reviewing and thinking about the multiple challenges we faced, we came up with various possible solutions.

The first option was to build a new database and codebase. However, this would require a lot of scripts for migrations, resetting passwords without user consent, and building a whole new user experience for old and new users.

Another potential solution would be to use one of our existing code bases. In this case we are not making progress and we are not adding innovation.

Lastly, we could use authentication across accounts, via OAuth or some other authentication solution.

So what did we decide?

After weighing pros and cons, we ultimately decided to build a new user management service, with design changes made via existing code bases. Our goal will be to migrate users from a number of different products without adversely affecting their experience across platforms.

Next steps for us are to investigate the right language, architecture, and approach to implementing changes. (And we are focused on using more microservices as we believe in using a separation responsibilities design pattern).

For programming, we are considering PHP, NodeJS and Go. And for storing information, we are considering relational databases such as Postgres, MySQL, etc.

This quarter, we built a POC (proof of concept) that tested successfully. In the coming months, we will continue to flesh out the system and begin rolling out our new unified user management system across platforms.

Looking for a new job opportunity? Become a part of our team! We are always looking for new Insiders.