Because Zoosk is a dating website, photos are an integral part of our users’ experiences. Having a good profile photo helps Zoosk’s users make good first impressions. This is why we are continuously trying to identify better ways for users to upload, edit, and maintain their photo galleries.
A user’s photo gallery consists of information about:
This information is stored in a relational database.
Photo System v1
The initial version of Zoosk’s photo system was a library of helper functions written in PHP that defined the interface to our underlying distributed file storage systems like Mogilefs, Amazon S3, and ImageMagick extension. The gallery information about the photos was combined into a relational database.
Photo System v2
One of the first enhancements we wanted to make to Zoosk’s photo system was to convert it into a service, so that we could separate it from Zoosk’s core codebase. We could separate the library dependency, like ImageMagick, from our API servers. To achieve this we built a thrift interface between our API tier and the photo tier then moved all the necessary library and photo-relational database behind the service. The service was implemented in PHP using the ImageMagick library. Although this solved our code maintainability and library dependency, it did not add any enhanced benefits for the user. The system still had a lot of flaws.
To address these issues we took the following steps.
Even with these enhancements the time it took a Zoosk user to upload a photo did not change or see any improvement.
Photo System v3
Photo System v3 was truly a dynamic photo generation system. First we hosted the system on Amazon EC2 so that we could decrease the time for access to S3. (S3 was our backend photo storage system, so it made logical sense to have this photo system in EC2.) We also moved the gallery from the user database to Photo System v3, which allowed us to independently maintain Zoosk member galleries and not worry about calling the API tier back.
This is how the new system worked:
From the photo id, we got all the crop information needed from the database. This involved getting the edit information applied by the user and also the exif information present in the image itself. (Generally the photos would have exif information, which would give us information about the orientation of the image, such as height and width.) This exif information was used along with the edits the user made to get the resulting image. The size of the resulting image came from the URL too. This solved most of our problems.
Advantages of our current photo system:
Migrating from Photo System v2 to Photo System v3
One of the biggest challenges of building such a big system was managing the switch from Photo System v2 to Photo System v3. Photo System v2 was live for close to six years and had millions of members’ profile photos. We also had a few hundreds of Terabytes of images on S3 buckets, which were getting served by Photo System v2 that needed to migrate to the new system. Apart from this we were also getting live photo uploads at a rate of hundreds of thousands of uploads a day.
How did we migrate photos from an old system to a new system without affecting the user experience?
To achieve this we designed some changes in the API tier. We rolled this out in phases.
We built a dynamic photo system that can generate different sizes of photos on the go and significantly reduced the photo upload time. This also reduced the overall response time of the website and increased user engagement by 2%.