From 621db72eac0643abc1e052bc0cf8babd90565220 Mon Sep 17 00:00:00 2001 From: benjaminramey Date: Tue, 22 Oct 2024 09:57:17 -0500 Subject: [PATCH] vault backup: 2024-10-22 09:57:16 --- Daily Notes/2024/10/2024-10-22 (Tuesday).md | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 Daily Notes/2024/10/2024-10-22 (Tuesday).md diff --git a/Daily Notes/2024/10/2024-10-22 (Tuesday).md b/Daily Notes/2024/10/2024-10-22 (Tuesday).md new file mode 100644 index 0000000..f4fcb56 --- /dev/null +++ b/Daily Notes/2024/10/2024-10-22 (Tuesday).md @@ -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