benjaminramey/ObsidianJournal
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2024-10-22 10:29:09

Browse Source
This commit is contained in:
Benjamin Ramey
2024-10-22 10:29:10 -05:00
parent 9fc75cb187
commit a2fbd75c20
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
Daily Notes/2024/10/2024-10-22 (Tuesday).md
View File

@@ -1,7 +1,7 @@
# Work # Work
A few learnings from launch morning: 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 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. I feel somewhat justified in my scale-up decisions before Bradley steam-rolled them with his own. But I don't regret going higher than needed versus an alternative of not going high enough and having to scale-up in the middle of launch day.
2. Caching was a big win, at least in the short term 2. Caching was a big win, at least in the short term--perhaps we fall off the horse on the "no pre-emptive optimization" horse and _should_ cache rarely-changing data much more often?
3. Our code felt sloppily crafted. What I mean is: 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 appears that *zero* thought was put into actually taking advantage of doing this in bulk and/or parallel 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 appears that *zero* thought was put into actually taking advantage of doing this in bulk and/or parallel
2. Caching was not carefully implemented (ie, not implemented at all in obvious places) 2. Caching was not carefully implemented (ie, not implemented at all in obvious places)
@@ -10,5 +10,5 @@ A few learnings from launch morning:
1. Some of our most experienced senior engineers (who also had the most senior insight into what Commerce and Payments was doing) leaving shortly before launch (Nate Merritt and Timothy Baumgartner). This left us not only short-handed, but also not knowing what we didn't know in some cases. I can't point to specific problems that I could draw a direct from to them leaving, but it feels like some problems may have simply been caught and never appeared as an issue long before launch. 1. Some of our most experienced senior engineers (who also had the most senior insight into what Commerce and Payments was doing) leaving shortly before launch (Nate Merritt and Timothy Baumgartner). This left us not only short-handed, but also not knowing what we didn't know in some cases. I can't point to specific problems that I could draw a direct from to them leaving, but it feels like some problems may have simply been caught and never appeared as an issue long before launch.
2. Time: teams were working up to the last minute on things. We had little time to optimize, refactor and improve code. 2. Time: teams were working up to the last minute on things. We had little time to optimize, refactor and improve code.
3. Legacy design decisions: my impression (not quite a fully educated one) is that we regret a lot of design choices around Subscriptions API (and subscribable products specifically). This has a lot to do with the "web of interconnected services" I mentioned above. 3. Legacy design decisions: my impression (not quite a fully educated one) is that we regret a lot of design choices around Subscriptions API (and subscribable products specifically). This has a lot to do with the "web of interconnected services" I mentioned above.
5. 5. A better pla
# Meetings # Meetings