vault backup: 2024-10-22 09:57:16

This commit is contained in:
2024-10-22 09:57:17 -05:00
parent 25499ad1b9
commit 621db72eac

View File

@@ -0,0 +1,12 @@
# Work
A few learnings from launch morning:
1. At our highest traffic points, Web server and DB server performance were _never even close_ to hitting any limits whether CPU, memory, disk space, etc
2. Caching was a big win, at least in the short term
3. Our code felt sloppily crafted. What I mean is:
1. Routes like the Orders API bulk preview route were _grossly_ inefficient. While it was (apparently) created to allow doing multiple previews at once, it appear that *zero* thought was put into actually taking advantage of doing this in bulk and/or parallel
2. Caching was not carefully implement (ie, not implement at all in obvious places)
3. We have a ridiculous web of interconnected microservices. Discounts, orders, products, subscriptions--none of them are stand-alone services. They all depend on each others, it seems. I believe there has not be careful planning around the boundaries of these APIs and, unless replatforming supplants them completely, we need some major overhaul or at least strongly-worded guided on incremental improvements as we maintain these services
4. I see a couple of potential causes for this "carelessness":
1. Our most experienced senior engineer (who also had the most senior insight into what Commerce was doing) leaving two months before launch (Nate Merritt)
2.
# Meetings