About the project

YewSocial are the industry leaders in organic Instagram growth, they help people gain real followers, likes and comments from real people that are genuinely interested in their customers profile.

This was one of those internally mammoth websites that agencies like us thrive on attaining, not just because of the monetary value of such larges websites but the extremely welcomed pride we receive as a team for being able to complete.

We created this website, and it's aforementioned mammoth internals from nothing but an existing proprietary software solution provided by the owners, and an idea.

yewsocail mock
yewsocail mock2
yewsocail mock3

Our Challenges

1

What kind of data are we working with?

We discovered that we would be responsible for dealing with delicate information, such as account passwords and we never condoned the idea of these being stored in plain text so instead, they're encrypted using the 448-bit blowfish algorithm and decrypted on the platform end.

We also knew that we would need to accrue millions-on-millions of statistical entries about the progression of individual accounts,  the state of the servers and would have to keep those records for at least 5 years so we needed a dedicated server for the MySQL server alone and we jumped at the opportunity to use Amazon's scalable server.

A few months into it's life there is already 25GB of data stored.

2

Servers are created and dismantled on demand, with each new server having a new IP, alongside that how do you intend to send the server a configuration when the platform doesn't accept any inbound communication.

As they say if you want the good things you have to go and get it, and in this scenario the "good thing" was the server configuration and in like an act of code-jebus the platform contained the ability to fetch configuration's from a file.

Essentially, we created a private API where all servers check in the moment they have completed their instantiation to have their existence acknowledged, if an account was waiting for a server then when it checked in it would be immediately assigned a new configuration. Each server required it's own unique API key which was granted to it on creation and it would use that to communicate with the API.

A simple localhost server was packaged with the AWS image that gets used when creating new instances. The moment that server connected to the internet and was completely up and running the only task of that localhost server was to send a request to the hub saying "Hello! I'm alive!", retrieve the configuration, save the response to a file and then boot the platform via command-line with an argument to load the custom configuration.

Contact us