Frendy retail case study
Frendy database on AWS
Established in 2019, Frendy is a social e-commerce platform encompassing all essential Indian retail categories. From branded apparel to stylish footwear, exclusive jewellery to sassy cosmetics, and elegant home and lifestyle products to your daily household needs and groceries, Frendy offers a wide range of products at discounted prices.
We understand the soul of the Indian customer who loves that little ‘extra’. So, while we connect a diverse community of Indian buyers and sellers, we have ensured that our customers get something more than just a great shopping experience.
At Frendy, through our unique community-based lifetime referral programme, we provide customer loyalty benefits and opportunities to earn like no other. To put it in simple words, Frendy is where customers can SHOP, SHARE & EARN.
As a team that’s growing by the day, we’re a frend(l)y bunch of enthusiastic, experienced and like-minded youngsters who are up to creating an exclusive online ‘shopping and earning’ experience. The leadership in which each member has over 15 years of experience, encourages and embraces novel ideas.
Frendy is individually funded by promoters of Pacifica Companies, a US $4 bn Real Estate enterprise headquartered in San Diego near Silicon Valley and Nebula Companies, a real estate company based out of India.
As we know frendy is a community ecommerce platform focusing on 3 essential aspects – Shop, Share, and Earn. The platform encourages coming together of friends and rewards them for shopping and building a community.
Challenge faced by customers “To serve the ecommerce platform to customers, there is a lack of flexibility, reliability and security of data”.
Other challenges –>
- There is an issue in performance of the website due to the increase in the number of concurrent users.
- There is an increase in workload which can affect the performance of websites (Site goes down).
- There is an issue in generating reports due to the size of the report.
We have configured and delivered AWS RDS Database in the Mumbai region(ap-south-1).
Below are the resources configured →
- Created a VPC in production environment.
- Created subnets in production environment.
- Created Security Group with inbound rule for port of rds and outbound rule for all traffic allowed from anywhere.
- Created a RDS in production environment with a new parameter group and required parameters such as version, storage and instance type.
- Enabled logs for monitoring purposes such as audit, general, error and slow query.
Solution which has applied to resolve the challenge as →
- In rds, configured a Performance Insights option to check the number of queries running by concurrent users.
- In rds, also configured a default Key Management Service to encrypt the rds data with 7 days retention.
- Configured inbound and outbound rules as per verifying the security of rds in vpc security group option.
- To resolve the issue of performance of the website, we have increased the storage to 200GB which provides the number of read/write iops which increases the throughput.
- To resolve the issue of heavy workload duration when the site goes down or gets slow, we have set storage auto scaling option enabled and set its value of maximum storage threshold to 250GB.
- To resolve the issue of generating the huge size report, we have updated the parameter group of rds as parameter – max_execution_time, to sufficient generating report.
- Solutions deployed in rds database make the architecture highly reliable and scalable. Security of data and cost optimization are successfully completed.
- Fine tuning of some DB parameters improves performance significantly.
- DB read replica off load select queries and reduce load on primary DB.
- Auto Scaling help dynamic load balancing for App Tier
- Performance of the website is increased and workload is balanced as per customer requirement.
Database is one of the critical component to handle dynamic workload.
Auto scaling improve scalablity and performance for App layer but some time increase pressure on DB layer.
Read replica should be carefully used to keep balance between performance and cost .