Scaling our Laravel app, after a flash sale took down our MySQL database
Вставка
- Опубліковано 18 тра 2024
- #webdevelopment #laravel #developer #devops #mysql #redis #caching
In this video I talk about how a sudden spike in traffic (ie. a Flash Sale) took down our database and Laravel app. Learn how we effectively scaled our app using an effective Redis caching strategy.
Shopify pod-based architecture: shopify.engineering/a-pods-ar...
00:00 - Introduction
00:25 - The camping site
01:08 - The day of the flash sale
02:05 - How we got here
02:47 - Our caching strategy
04:16 - Final takeaways
Great video. Covered the topic wonderfully.
Thx, glad you liked it!
This is great content! Please share more insights like this. It'd be great to get more technical details and code examples next time.
Thanks, will do!
Very nice video! I subscribed 💯
Thanks for the sub!
Show us how to setup it
Good suggestion!
ahhhh the "MySQL has gone away problem" :))
add more load palancers
How would this help? Also you can not just load-balance to different MySQL servers If you really want this you need a Cluster (Or a Master-Slave but then you need to configure Laravel to send inserts and updates to the master and selects to the slaves - so not exactly a simple load balancer) a smart caching strategy is way cheaper.
Agreed! Even though Amazon RDS makes read/writes replicas easy nowadays, good caching strategies are often way cheaper.
Thanks for the video, by the way I'm working on a laravel Multi-Tenancy Database-Per-User application, where's the best place to host it and make it easy for me?
I'm a big fan of Laravel Forge! For a Database-Per-User application I'd look into a managed AWS RDS instance. We've recently done a migration off a self-managed database into AWS RDS, and never looked back. So our setup is as follows:
- We have a LoadBalancer + 3 application servers on Laravel Forge (with Linode/DigitalOcean as a provider)
- Our 3 application servers connect to a managed RDS MySQL Database
The latency between Linode & AWS is negligible, but we could opt for migrating everything to AWS EC2 so it lives 'closer' to our RDS Database.
@@sabatino_masala Thank you very much
Thanks a lot for making these videos! They're really useful for understanding the thought process and the insights you've gained from the challenges you faced.
Do you have experience with autoscaling Laravel apps? E.g. Laravel Vapor/AWS Lambda or Kubernetes
Thanks! I've dabbled with Laravel Vapor, but for most of my projects of scale I use AWS EKS.
what resources did the vps have? cpu and ram and storage
It was a Linode VPS, 16GB of ram, 6 CPU’s and 320GB of SSD storage (+- $100/month).
How are you different from shopify?
We’re focused on restaurants & snackbars (fast food). Our system is built specifically for these use-cases. I’ll give you an example: in Belgium it’s required to have a registered POS. We have such a license (and had to jump to a massive amount of hoops to get it), Shopify does not.
If we were to expand into retail, we will get into Shopify territory. Currently we’re in a different niche.
@@sabatino_masala Okay cool!
Whats the sites domain?
The system is called Unipage (unipage.be)
Foodticket ? :P
🎫
40 query per page? you should start from there :"
You’d be surprised how fast you get there 😅
@@sabatino_masala I worked on a multi tenant ecommerce before with postgresql (db schema per merchant) it's 5-7 queries max.
max query number I got was on creating orders, it was 11 then minimized it to 7 as well, but I had to rewrite my forms without using the built-in solution, maybe you've something more advanced
These things drive our queries up:
- domain resolving
- loading products
- loading product availability
- open timeslots
- taken timeslots (for disabled state)
- delivery regions & configuration
- previous orders (‘ordered before’ functionality)
- most popular products
- upselling products
- active promotions
… the list goes on
A decent caching strategy was so important for us to be able to scale.
Impressive you got the job done in 5-7 queries! Our use case simply didn’t allow low query counts without caching mechanisms & async calls.
@@sabatino_masala As I thought, you've something more advanced
I was using redis to resolve domain to schema name
was caching most selling products, categories and shipment regions
products listing was just one query, it was one big query with subqueries but works fine
Guess I'll need to check your ideas to see what I'm missing
Userid and user data caching is reaaaaaally standard, if you didn't do that, then you are doing it wrong.
Not really, because we were building features fast instead of worrying about caching 👍
@@sabatino_masala There is a difference in lean and bad design. You mentioned the app was 10 years old and worked fine. It means you shipped that for production and not a proof of concept. Yeah, I didn't mean this as harsh criticism, we all learn. Learn and live.