Let’s Debunk the WooCommerce Scaling Myth  🔗 **Source:** [Let’s Debunk the WooCommerce Scaling Myth](https://www.youtube.com/watch?v=DZ_2DuuHTOE) > [!note]+ Document Notes > tags: [woocommerce, ecommerce-scaling, caching, web-performance, ai-site-operations] > author: WP Minute Podcasts > source: The WP Minute > reference: https://www.youtube.com/watch?v=DZ_2DuuHTOE > date created: 2026-09-14 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Let's Debunk the WooCommerce Scaling Myth > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Episode page: Let's Debunk the WooCommerce Scaling Myth (The WP Minute, published 2026-09-14)](https://thewpminute.com/lets-debunk-the-woocommerce-scaling-myth/) - [YouTube: WP Minute Podcasts upload](https://www.youtube.com/watch?v=DZ_2DuuHTOE) - [Urumi (guest's company)](https://urumi.ai/) - [WooCommerce developer docs: High-Performance Order Storage](https://developer.woocommerce.com/docs/features/high-performance-order-storage/) - [WooCommerce developer blog: Performance benchmarking for WooCommerce HPOS (2023-03-17)](https://developer.woocommerce.com/2023/03/17/performance-benchmarking-for-woocommerce-hpos/) - [WooCommerce developer blog: The plan for the WooCommerce custom order table (2022-01-17)](https://developer.woocommerce.com/2022/01/17/the-plan-for-the-woocommerce-custom-order-table/) - [WooCommerce developer docs: Configuring caching plugins](https://developer.woocommerce.com/docs/best-practices/performance/configuring-caching-plugins) ## 📝 Summary - **What happened:** Eric Karkovack hosts a 29:20 episode of The WP Minute+ podcast with Vedanshu Jain, whom the episode page lists as CEO and co-founder of Urumi AI and a former WooCommerce technical lead. Jain says WooCommerce has no fixed scaling ceiling: the limits merchants hit come from uncacheable cart and session requests, bot crawls of large catalogs, and slow code paths, and each has a fix. - **Why it matters:** The episode pairs a first-hand account of the High-Performance Order Storage (HPOS) rollout, which moved orders out of `wp_posts`/`wp_postmeta` into four dedicated tables, with a vendor pitch for AI-run hosting. WooCommerce's own 2023 benchmark reports 5.1x faster order creation and 40x faster filtering by customer ID with HPOS, which backs the "WooCommerce can scale" half of the argument with first-party numbers. - **Key stakeholders:** WooCommerce merchants, freelancers and agencies who host stores, plugin authors whose code still reads order data from post tables, managed hosts, and the WooCommerce core team. - **Risks and tradeoffs:** The guest sells the solution the episode describes, and most numbers (a store doing $1M a year on $100–$200/month hosting, a 400,000-product catalog, a 1:5 to 1:10 human-to-bot ratio, a customer with "billions in revenue") are unverified anecdotes. AI agents that hot-patch third-party plugins and remove the update button move update decisions from the merchant to the host, which raises review and disclosure questions the episode doesn't address. - **Bottom line:** The mechanism claims (cart state defeats page caching, HPOS removed an order-storage bottleneck, autoscaling trades fixed headroom for per-use cost) match WooCommerce's first-party docs. The market prediction (open-source commerce "would absolutely dominate the market" in 5 years) and the Urumi-specific results carry no evidence in the episode. ## 📖 Main Content - **Core argument 1, HPOS removed a structural bottleneck.** Jain says they led the HPOS project, which moved order storage from the WordPress posts tables to dedicated order tables. WooCommerce docs name the tables `_wc_orders`, `_wc_order_addresses`, `_wc_order_operational_data`, and `_wc_orders_meta` (with the site's table prefix). Jain says implementation took about 1 year and reaching default-on for new sites took 1 more. The public record fits that estimate: the plan post ran 2022-01-17, the early-adopter call came in May 2022, HPOS shipped as opt-in in WooCommerce 7.1, and WooCommerce 8.2 (October 2023) enabled it by default for new installs. - **Core argument 2, "inversion of blame" as a rollout principle.** The team treated a broken store as the project's failure, not the merchant's. Jain lists the mechanisms: outreach to third-party plugin developers, "upgrade parties" with real-time support, documentation, a sync mode that keeps writing to the old post tables so unported plugins keep working, and incompatibility warnings in the admin. The HPOS docs confirm the compatibility-mode sync and a `wp wc cot sync` CLI command. - **Core argument 3, the real bottleneck is uncacheable requests.** A plain WordPress site serves most requests from a page cache. Jain says a WooCommerce request stops being cacheable once a visitor adds to cart, and a plugin that sets a session cookie can make even the homepage uncacheable. WooCommerce's caching guide supports the mechanism: it tells you to exclude Cart, My Account, and Checkout and to bypass cache for the `woocommerce_cart_hash`, `woocommerce_items_in_cart`, `wp_woocommerce_session_`, `woocommerce_recently_viewed`, and `store_notice[notice id]` cookies. Jain's fix list: cache as much as possible, load add-to-cart state by Ajax after render, or buy more PHP workers. - **Core argument 4, bots are a cache-capacity problem, not a checkout problem.** Jain says a site with 100–500 products can cache every page a crawler hits. A catalog of 400,000 products with 100,000 changing daily (a customer anecdote) outgrows cache capacity, so page generation speed decides whether the site holds up. They say bots outnumber humans by 5x to 10x across Urumi-managed sites (speaker estimate; the caption's ratio direction is ambiguous) but don't add to cart or check out. - **Core argument 5, AI operations plus autoscaling.** Jain describes Urumi's system as request tracing that finds slow code paths, AI-generated fixes, hot patches sent upstream to plugin authors, Kubernetes-based autoscaling, staging "workspaces," an AI QA pass that writes reusable test scripts to limit token spend, and no plugin update button on production. These are the guest's descriptions of their own product. Urumi's blog post (Vedanshu Jain, updated 2026-08-26) confirms upstream fix submission ("including to Automattic") and managed APM. The post doesn't mention Kubernetes. - **Terms defined.** - *HPOS*: High-Performance Order Storage, WooCommerce's dedicated order tables (captions render it "HPS"). - *PHP workers*: the number of PHP processes a host allows at once, which caps concurrent uncached requests. - *Traces*: per-request timing records that show where a request spends its time. - *Autoscaling*: adding or removing servers as request volume changes. - *Agentic commerce*: AI assistants placing orders on a shopper's behalf. - **Uncertain or contested claims.** - The "20% utilization at peak, 80% headroom" figure for static servers is a rule of thumb the guest attributes to general practice without a source. - "WooCommerce… is just another PHP application. And it can scale to whatever you want it to" skips the database and session layers, which don't scale horizontally the way stateless PHP containers do. - The claim that "an existing host" pushes merchants to migrate to BigCommerce names no host and goes unverified here. - Urumi's founders page lists Naman Malhotra and Vedanshu Jain. A search summary of a Repository newsletter article named a different co-founder, and that article returned HTTP 403, so the co-founder question stays unresolved. - **What I verified and what I didn't.** - *Verified:* host identity (Eric Karkovack hosts The WP Minute podcast, per karks.com and the episode page's "Eric"), guest name and company spelling (Urumi, from show notes), HPOS tables and default version, HPOS benchmark numbers, caching exclusions, the `wc_update_product_stock` single-query design, and Brian Coords's role as a WooCommerce developer advocate. - *Not verified:* the woocommerce.com case study customer, every revenue and traffic figure, the former "starshot.app" name, Jain's authorship of the oversell fix, and the Kubernetes stack. ## 🗒️ Notes #### ⏱️ [0:01](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=1) Intro: the "ceiling" narrative - Eric Karkovack frames the episode around the idea that WooCommerce can't keep up once a store reaches a certain size. - Guest: Vedanshu Jain, introduced as co-founder and CEO of "Urmi AI" (caption spelling; the episode page spells it Urumi AI), a managed WooCommerce infrastructure platform. #### ⏱️ [1:18](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=78) Background at Automattic - Jain says they worked on the WordCamps team first ("camp takes," likely CampTix; caption spelling; unverified), then joined WooCommerce core in 2019, spent 5 years there, and ended as technical lead. - Their WordPress.org profile (vedjain) shows Meta Contributor '18, Meetup Organizer '19, and WordCamp Speaker '19 badges. #### ⏱️ [1:47](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=107) Leading HPOS - Jain calls HPOS ("HPS" in captions) the project that moved orders from post tables to dedicated order tables and unlocked performance work that was "really hard to work around earlier." #### ⏱️ [2:15](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=135) First project: stop overselling - Jain says concurrent buyers of the same product could push stock negative, and fixing it was their first core assignment. - The WooCommerce code reference describes `wc_update_product_stock` as running direct queries instead of `update_post_meta`, so a stock change happens in one query "to avoid stock issues" (@since 3.0.0). I didn't confirm which release carried Jain's fix. #### ⏱️ [3:07](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=187) Why HPOS was hard - Jain says the code was the easy part. Third-party plugins, custom themes, and custom code still read and write order data in the post tables. - The constraints: orders keep flowing, and merchants without technical staff can toggle the setting safely. #### ⏱️ [4:23](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=263) Inversion of blame - Jain's rule: you can't blame the merchant for clicking a setting or skipping the docs. - In practice that meant developer outreach, "upgrade parties" where plugin authors ported code with live team support, and constant availability. > [!quote] ID:rw_01m2g43dye79pqnpvft83y1avm > If something goes wrong, we cannot blame the operator of the site, which is often the merchant #### ⏱️ [5:28](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=328) Safety mechanisms and the 2-year timeline - The safeguards Jain lists are documentation, sync to the old tables, and incompatibility warnings. - Implementation took about 1 year, and default-on for new sites took 1 more (speaker estimate; consistent with the January 2022 plan post and the October 2023 WooCommerce 8.2 default). #### ⏱️ [7:04](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=424) Founding Urumi - Jain calls AI one of the biggest changes of their career. - They say the company started as "starshot.app," a performance and scaling platform, then rebranded to add AI (unverified; Urumi's blog post doesn't mention the earlier name). #### ⏱️ [8:04](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=484) Open source versus closed source for AI - Jain says Shopify data is split across third-party app servers that "even Shopify doesn't have direct access to," while an AI working on WooCommerce can read the code and the database. #### ⏱️ [9:03](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=543) "There is no ceiling" - Jain says merchants shouldn't have to migrate to BigCommerce "like an existing host wants you to do." That's the speaker's unnamed claim, unverified. #### ⏱️ [10:06](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=606) The bottleneck: cart state beats caching - A WordPress site serves most requests from cache. After add-to-cart, a WooCommerce request can't be cached. - Plugins that set session cookies can make the homepage uncacheable too. > [!quote] ID:rw_01m2g43kc9gb078drgz1k9sz5c > With WooCommerce, for example, once you add something to the cart, it's that request cannot be cached anymore, right? #### ⏱️ [11:41](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=701) Budget hosting can go far - Load add-to-cart as an Ajax request after render, then add PHP workers or a larger server if needed. - Anecdote: sites doing "1 million per year on like $100 per month hosting or like 150 or $200" (unverified). - Jain qualifies it: order count, average order value, paid Meta ads, and organic traffic all change the answer. #### ⏱️ [12:53](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=773) Bots and agentic commerce - Karkovack cites an earlier episode with "Brian Cordes" (caption spelling). Brian Coords is a developer advocate at WooCommerce, which fits the context. - Per Karkovack, that episode covered ordering from a WooCommerce store inside ChatGPT (I didn't check the earlier episode). Karkovack asks whether caching can handle bot load. #### ⏱️ [13:22](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=802) Catalog size decides whether caching absorbs bots - A store with 100–200 products can cache every page. - A customer with 400,000 products cycles 100,000 of them daily, and crawlers re-enumerate them (anecdote, unverified). > [!quote] ID:rw_01m2g43pwqc9qyk5kjv14ygbys > they have like, you know, 400,000 products. They cycle through 100,000 products every day. #### ⏱️ [14:35](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=875) Two responses: faster pages and cache capacity - Jain says you can optimize initial page load with Claude, ChatGPT, or Gemini ("Cloud" in captions; caption spelling; unverified). - Ask your cache provider (Cloudflare or a host's built-in cache) how much it holds. - Smaller product pages fill the cache more slowly. #### ⏱️ [15:25](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=925) Bot ratio and why it's tolerable - Jain gives a ratio of "1:5 to 1:10" across managed sites, with bots outnumbering humans (speaker estimate). - Bots don't add to cart or check out, so a well-cached site handles them and gains visibility in AI channels. #### ⏱️ [16:34](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=994) AI finds and fixes slow code paths - An AI monitors requests and reads traces to see where each request spends time. - It then fixes the slow code path automatically. #### ⏱️ [17:56](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=1076) Patches upstream - Jain says Urumi runs a hot patch and sends the fix to the plugin author with a request to ship it in the next release. - Urumi's blog confirms it submits fixes upstream "including to Automattic." #### ⏱️ [18:26](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=1106) Autoscaling versus peak provisioning - Static-server guidance, as Jain describes it: run at 20% utilization at peak to keep 80% headroom for viral spikes (rule of thumb, no source given). - Autoscaling adds servers as requests arrive and removes them when requests drop. #### ⏱️ [19:33](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=1173) Kubernetes - Jain says Shopify and "all the big companies" scale this way, and Urumi uses Kubernetes, which is less common in WordPress hosting than fixed servers. > [!quote] ID:rw_01m2g440kwg30wntb4n19e6r07 > But it's like really a really really popular way to scale this thing, right? Everyone uses it. #### ⏱️ [20:39](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=1239) Pay for what you use - Karkovack compares it to AWS-style billing: pay more on Black Friday while earning more. - Jain agrees that merchants getting orders don't mind paying for servers. #### ⏱️ [21:34](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=1294) AI repair in production - Jain says Urumi monitors slow requests, HTTP 500s, and "fitters" (likely fatals; caption spelling; unverified). - An AI finds the root cause and fixes it. #### ⏱️ [22:09](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=1329) Staging, workspaces, and AI-written tests - Deploys pass a QA path where an AI drives a browser through add-to-cart and checkout, writing scripts as it goes so later runs skip the model. - The AI steps back in only on failure. A real failure blocks the deploy. #### ⏱️ [23:28](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=1408) No update button - Production sites on Urumi show no plugin update button. The AI decides updates and asks the merchant about major changes. - Jain says one broken update teaches a merchant to fear the button and skip security patches. > [!quote] ID:rw_01m2g43v5zsfweg97vbawg5brx > Merchant wouldn't know that, you know, they would see an update button, they will click it, something will break. #### ⏱️ [24:44](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=1484) One-year outlook: many small issues - Jain describes WooCommerce's biggest drawback with the "by a thousand cuts" idiom: many small issues such as slow database paths and small bugs, none severe alone. - They say AI with full code and data access fixes them. #### ⏱️ [25:48](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=1548) Case-study customer - Jain says a Urumi customer appears as a scaling case study on woocommerce.com, with "billions in revenue" and "thousands of orders per hour." - Unverified: I didn't find or confirm the case study. Urumi's homepage names grüum, Do Amore, Valentte London, Comic Concepts, and Everly Wellness as customers. #### ⏱️ [26:52](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=1612) Five-year prediction - If hosts adopt AI operations, Jain predicts open-source commerce platforms "would absolutely dominate the market" within 5 years. - Karkovack calls it a win for open source and for WooCommerce. #### ⏱️ [28:12](https://www.youtube.com/watch?v=DZ_2DuuHTOE&t=1692) Contact and close - Jain says they're reachable on WordPress Slack, WooCommerce Slack, email, and a signup form on urumi.ai. - The host thanks "Pranav" at 28:42, a caption error or verbal slip. The guest is Vedanshu Jain. ## 📚 References - [The WP Minute: Let's Debunk the WooCommerce Scaling Myth (show notes, host, guest, links)](https://thewpminute.com/lets-debunk-the-woocommerce-scaling-myth/) - [Eric Karkovack Web Design Services: Now hosting The WP Minute podcast](https://www.karks.com/now-hosting-the-wp-minute-podcast/) - [WooCommerce developer docs: High-Performance Order Storage (tables, sync, 8.2 default)](https://developer.woocommerce.com/docs/features/high-performance-order-storage/) - [WooCommerce developer blog: Performance benchmarking for WooCommerce HPOS (2023-03-17; ~400,000 orders, 30,000 products)](https://developer.woocommerce.com/2023/03/17/performance-benchmarking-for-woocommerce-hpos/) - [WooCommerce developer blog: The plan for the WooCommerce custom order table (2022-01-17)](https://developer.woocommerce.com/2022/01/17/the-plan-for-the-woocommerce-custom-order-table/) - [WooCommerce developer docs: Configuring caching plugins (excluded pages and cookies)](https://developer.woocommerce.com/docs/best-practices/performance/configuring-caching-plugins) - [WooCommerce docs: Scaling FAQs ("100,000+ products listed, handling thousands of transactions per minute")](https://woocommerce.com/document/woocommerce-scaling-faqs/) - [WooCommerce code reference: wc-stock-functions.php (`wc_update_product_stock`)](https://woocommerce.github.io/code-reference/files/woocommerce-includes-wc-stock-functions.html) - [Urumi homepage (founders, customer names, performance claims)](https://urumi.ai/) - [Urumi blog: How we built the fastest WooCommerce hosting (Vedanshu Jain, updated 2026-08-26)](https://urumi.ai/blog/how-we-built-the-fastest-woocommerce-hosting-and-the-advent-of-self-healing-software) - [WordPress.org profile: vedjain](https://profiles.wordpress.org/vedjain/) - [Do the Woo: Scaling WooCommerce, insights on HPOS with Vedanshu Jain](https://dothewoo.io/scaling-woocommerce-insights-on-high-performance-order-storage-hpos-with-vedanshu-jain/) - [WooCommerce developer blog: Brian Coords author page](https://developer.woocommerce.com/author/bcoords/) - [WordPress.tv: Case study, scaling a WooCommerce store from 16k to 6.5M in 3 years (2024-11-27; title from search result, not watched)](https://wordpress.tv/2024/11/27/case-study-scaling-a-woocommerce-store-from-16k-to-6-5m-in-3-years/) ## 🗣️ Paraphrase - **0:01–1:47.** The host opens with the claim that WooCommerce stops keeping up past a certain store size and brings on a former WooCommerce technical lead who disagrees. The guest recounts moving from the WordCamps team to WooCommerce core in 2019 and leading HPOS. - **2:15–3:46.** The guest's first core job was stopping stock from going negative when buyers raced for the same item. HPOS was harder for social reasons than technical ones, because thousands of plugins and custom themes still touched order data in the post tables. - **3:46–6:37.** The team refused to blame merchants for breakage. They recruited plugin authors to "upgrade parties," staffed live support, wrote docs, kept the old tables in sync, and showed warnings for incompatible plugins. About 1 year went to building HPOS and another to making it the default for new stores. - **7:04–9:34.** The guest started a performance company, then rebranded it around AI because an AI can read open-source code and a store's whole database, unlike a Shopify store whose data sits in third-party apps. - **9:34–12:20.** Plain WordPress sites scale with page caching. WooCommerce loses that once a shopper adds to cart or a plugin sets a session cookie. Careful cache setup and Ajax cart updates let a store run on budget hosting, and some stores the guest has seen make $1M a year on $100–$200 monthly plans, depending on orders and traffic mix. - **12:20–16:34.** Bots crawl every product. Caching covers a few hundred products but not a catalog that churns 100,000 items a day, so page speed matters. Bots outnumber humans 5x to 10x on the guest's managed sites but don't check out. - **16:34–21:34.** Urumi reads request traces, has AI fix slow paths, sends patches to plugin authors, and autoscales on Kubernetes instead of paying for servers sized to sit at 20% utilization at peak. - **21:34–24:44.** Deploys run through staging and an AI-driven browser test that turns into a reusable script. Production has no update button, because merchants who break a site once stop applying updates, security fixes included. - **24:44–29:20.** The guest expects AI to fix WooCommerce's many small problems, cites a large customer featured on woocommerce.com, and predicts open-source commerce will dominate within 5 years if hosts adopt AI operations. ## 📰 Newsletter - **Why WooCommerce stores slow down after add to cart.** On The WP Minute+, Eric Karkovack talks with Vedanshu Jain, a former WooCommerce technical lead who led High-Performance Order Storage, now running Urumi AI. Jain's diagnosis: once a shopper adds to cart, that request skips the page cache, and a session cookie set by a plugin can drag the homepage along with it. [Listen to the episode](https://thewpminute.com/lets-debunk-the-woocommerce-scaling-myth/). - **Check your cache rules against the source.** WooCommerce's [caching guide](https://developer.woocommerce.com/docs/best-practices/performance/configuring-caching-plugins) lists the pages to exclude (Cart, Checkout, My Account) and the cookies that must bypass cache, including `woocommerce_items_in_cart` and `wp_woocommerce_session_`. - **HPOS numbers worth citing.** WooCommerce's [2023 benchmark](https://developer.woocommerce.com/2023/03/17/performance-benchmarking-for-woocommerce-hpos/) on a 400,000-order store: order creation 78.12s to 15.18s for 1,000 orders, customer-ID filtering 0.60s to 0.02s. HPOS has been on by default for new stores since WooCommerce 8.2 in October 2023. - **A rollout lesson for plugin and core teams.** Jain's "inversion of blame" treats a broken merchant site as the project's bug. It paired upgrade parties and a sync mode with the new tables, so plugin authors had a working fallback while they ported. - **Caveat.** The revenue and traffic figures in the episode are the guest's anecdotes, and the AI-operations features are descriptions of their own product. ## ✅ Action Items #### DevRel - **Developer advocacy:** Build a 20-minute talk, "Inversion of blame," comparing the HPOS rollout mechanics (upgrade parties, compatibility sync, incompatibility warnings, 2-year runway) with a WordPress core API change. Measure it by the number of plugin authors who adopt a compatibility declaration after the talk. - **Education:** Run a 60-minute office hour on WooCommerce cacheability. Load a test store, add to cart, and compare `Cache-Control` or cache-status headers on the homepage before and after, using the cookie list from WooCommerce's caching guide. - **Developer experience:** Draft a one-page quickstart, "Is my plugin making WooCommerce pages uncacheable?" Cover setting session cookies on first page load and rendering cart state server-side instead of by Ajax, the two causes Jain names at 10:36 and 11:41. - **Developer marketing:** In any "WooCommerce scales" content, cite the first-party HPOS benchmark (5.1x order creation, 40x customer filtering), not vendor case studies. Label host-provided numbers as vendor claims. - **Community management:** When sharing this episode in community channels, add a note that the guest runs a hosting company, so readers weigh the Urumi-specific claims accordingly. - **Internal/external/cross-project:** Ask WooCommerce DevRel (Brian Coords is a developer advocate there) whether an HPOS rollout retrospective exists publicly. If not, propose one as a reusable playbook for other large plugin migrations. #### OSPO - **Policy & Governance:** Write a question list for hosts that AI-patch third-party GPL plugins in production: who reviews the patch, how the site owner learns a patched version is running, and when the patch is removed after upstream ships a fix. - **License Compliance:** Not applicable to this source. The episode mentions hot patches to plugins but gives no detail on distribution or licensing, so there's nothing to review. - **Security Management:** Map the guest's "no update button" model to vulnerability response. Record who applies a security release, the target time from disclosure to patch, and how a merchant can force an update when the AI waits. - **Software Inventory:** For hosted stores with hot-patched plugins, track plugin version plus patch ID, since a stock version number no longer describes the running code. - **Developer Support:** Not applicable to this source. The episode covers no internal tooling or legal consultation for developers. - **Community Engagement:** Track upstream patch acceptance. The guest says Urumi sends fixes to plugin authors (17:56), and the Urumi blog says fixes go upstream "including to Automattic." A public list of merged PRs would let others verify it. - **Strategic Alignment:** Not applicable to this source. There's no organizational KPI or roadmap content. #### Community - **Maintainers:** Offer plugin maintainers a checklist from the HPOS migration: declare compatibility, read and write orders through the `WC_Order` APIs instead of post meta, and test with compatibility sync on and off. - **Contributors:** Pair new WooCommerce contributors on "small cuts" issues (slow queries, minor bugs), the category Jain calls WooCommerce's largest drawback at 25:18. - **Sponsors:** Not applicable to this source. No sponsorship or funding discussion. - **Ecosystem:** Propose a cross-host drill for Black Friday load: a shared test plan covering add-to-cart, checkout, and a crawler hitting 100,000 product URLs, run on any host's staging environment with results published per scenario, not per host. #### WordPress - **Core:** Use HPOS as the precedent when discussing any core table migration. Dual-write sync kept unported plugins working from opt-in (WooCommerce 7.1) to default-on for new installs (8.2, October 2023). - **Core Performance:** Add a stateful-store scenario to performance discussions: measure time to first byte for uncached cart-bearing requests on a store with 30,000 products (the HPOS benchmark catalog size), since page-cache results don't reflect those requests. - **Core AI:** Draft guardrail questions for AI agents that modify plugin code on live sites: evaluation set (did the patch preserve checkout?), human review threshold ("major" changes, per the guest at 23:52), and audit logging. - **Core Program Team:** Document "upgrade parties" (scheduled sessions where authors port code with live team support) as a coordination ritual for cross-team breaking changes, with the HPOS rollout as the reference case. - **Mobile:** Not applicable to this source. The episode doesn't discuss the WordPress or WooCommerce mobile apps. - **Playground:** Test whether a Playground blueprint can install WooCommerce, enable HPOS with compatibility sync on, and seed orders, so workshops can show the sync behavior without a host. - **Community:** Offer meetup organizers a talk outline on WooCommerce caching exclusions that uses the five cookies from WooCommerce's caching guide as the hands-on segment. - **Training:** Check Learn WordPress for an existing lesson on WooCommerce caching and HPOS before drafting one. If none exists, scope a lesson built on the two first-party docs cited here. - **Marketing:** Counter the "WooCommerce doesn't scale" narrative with first-party data: the Scaling FAQs line about "100,000+ products listed, handling thousands of transactions per minute" and the HPOS benchmark table. - **Support:** Create a forum reply template for "store slows after add to cart" that links the caching guide's excluded pages and cookies and asks for the store's PHP worker count. - **Design:** Review the HPOS incompatible-plugin warning as a pattern for admin notices that block a risky setting change until dependencies report compatibility. - **Documentation:** Propose a merchant-facing (not developer-facing) "safe updates" page: back up, update on staging, run a plugin conflict test, then update production. It addresses the fear-of-updating cycle Jain describes at 24:21. - **Photos:** Not applicable to this source. No image or media-library content. - **TV:** Pair this episode with the WordPress.tv talk "Case study: Scaling a WooCommerce store from 16k to 6.5M in 3 years" (2024-11-27) in a scaling playlist, after confirming the talk's content. - **Polyglots:** Not applicable to this source. The episode doesn't discuss translation or locales. - **Accessibility:** When a host's AI writes checkout test scripts (22:34), propose adding automated accessibility checks to the same add-to-cart and checkout path, so each deploy blocks on WCAG 2.2 AA regressions too. - **Meta:** Not applicable to this source. No WordPress.org site or API topics. - **CLI:** Note `wp wc cot sync` (WooCommerce's HPOS sync command, per its docs) in any migration guide that also cites WP-CLI steps, since hosts run batch sync from the command line. - **Hosting:** Propose a host-neutral WooCommerce checklist for the Hosting team handbook: cache exclusions for Cart, Checkout, and My Account, cookie bypass rules, the PHP worker count disclosed to merchants, and HPOS enabled. - **Tide:** Not applicable to this source. The episode doesn't discuss plugin code scoring. - **Openverse:** Not applicable to this source. No openly licensed media content. - **Themes:** Add a review check for WooCommerce-compatible themes: no session cookie set on anonymous first page load, so the homepage stays cacheable (the failure Jain describes at 10:36). - **Plugins:** Ask how directory plugin authors want to receive host-generated performance patches (GitHub PR, support forum, or security channel) and publish that preference in the plugin readme. #### The WPOCC - **Programs:** Not applicable to this source. The episode doesn't discuss fellowships, grants, or stipends. - **Projects:** Not applicable to this source. No governance or documentation sprint content. - **Funding experiments:** Not applicable to this source. No funding discussion. #### FAIR - **Technical independence:** When an AI agent picks and applies plugin updates with no merchant click (23:28), signature and provenance checks on the update package become the merchant's main safeguard. Note this as a use case for signed package metadata. - **Policies and covenants:** Not applicable to this source. No governance or anti-capture content. - **Productized governance artifacts:** Not applicable to this source. No charters or operator agreements discussed. ## 🧪 Hypotheses - **H1:** On a WooCommerce store behind a page cache, the share of origin-served (uncached) HTML requests per session rises after the first add-to-cart event, and rises again when any active plugin sets a session cookie on first load. - **H2:** On current WooCommerce releases, HPOS still outperforms post-table storage on a store with at least 400,000 orders by a margin similar to 2023's (5.1x order creation, 40x customer-ID filtering). - **H3:** On WooCommerce stores with more than 100,000 products, bot requests outnumber human requests by 5x or more, and bot-driven cache misses account for most origin load outside checkout. - **H4:** Stores whose host applies plugin updates automatically install security releases in fewer median days than stores where merchants click update. - **H5:** For stores with a peak-to-average traffic ratio above 5:1, autoscaled hosting costs less per month than static servers sized to 20% utilization at peak. - **H6:** Converting a first AI-driven checkout test into a saved script cuts model tokens on later deploy runs by more than 90%, with a false-block rate under 5%. ### 📊 Methodology - **H1:** - Deploy WooCommerce on a staging site with a page cache. - Script 500 synthetic sessions (browse, add to cart, checkout) with a browser automation tool. - Log cache-status headers per request. Compare hit rates before and after add-to-cart, with and without a cookie-setting plugin active. - **H2:** - Rerun WooCommerce's 2023 benchmark on the current release: ~400,000 orders, 30,000 products, memcached. - Report the same five operations, and publish the scripts. - **H3:** - Collect 30 days of access logs from 5 or more large-catalog stores. - Classify user agents plus behavior (no JavaScript execution, no cart events). - Compute bot:human ratios and each group's share of cache misses. - **H4:** - Pull plugin security-release dates from a vulnerability database. - For a sample of stores, record when each patched version appeared on the site, grouped by update model (auto versus manual). - Compare median lag. - **H5:** - Model monthly cost from real traffic curves of 10 stores under two plans: fixed servers sized for peak at 20% utilization, and per-minute autoscaling. - Use public per-instance pricing. - **H6:** - Log tokens and outcomes for 50 deploys: first run by an agent, later runs by saved script with agent fallback. - Count blocks, and label each true or false by manual review. ### ❓ Questions - Which woocommerce.com case study does the guest mean, and do its published numbers match "billions in revenue" and "thousands of orders per hour"? - When a host hot-patches a plugin, how does the site owner see which code is running, and what happens to the patch when the plugin's next release ships? - With no update button, how does a merchant force a security update the AI has deferred? - How does Kubernetes autoscaling handle WooCommerce's stateful layers (MySQL writes, sessions, object cache), which don't scale by adding PHP containers? - Does the 1:5 to 1:10 human-to-bot ratio hold outside one host's customer base, and how much of it comes from AI crawlers versus search engines? - What share of WooCommerce stores still run with HPOS compatibility sync on, and what does dual-writing cost them in checkout time? ### 🔮 Future Research - No public dataset compares WooCommerce cache hit rates by plugin set. A study that ranks common plugins by whether they set cookies on anonymous first load would give merchants a concrete audit list. - The HPOS benchmark dates from March 2023 on WooCommerce's pre-8.2 code. A rerun on current versions, with published scripts, would refresh the most-cited scaling evidence. - AI-authored patches to third-party plugins lack a disclosure norm. Research could survey plugin authors on how they want to receive them and how many they merge. - Agentic commerce traffic (AI assistants placing orders) will change the bot mix the guest describes. Tracking checkout requests from AI user agents over 12 months would test whether "bots don't check out" stays true. ### 💡 Implications - **Practice:** - Agencies hosting WooCommerce on budget plans can get further by fixing cache exclusions and cookie behavior before buying more PHP workers. - Plugin authors who set cookies on first load cost every store running them cacheability. - **Policy:** - Hosts that remove update controls and patch plugins take on update responsibility. - Terms of service and disclosure pages should say who's accountable when an AI patch breaks checkout. - **Security:** - Automatic updates can shorten time-to-patch, but an AI deciding to wait on a "major" update can also lengthen it. - Neither result is measured in the episode. - **Education:** - HPOS's rollout shows a large migration landing without breakage reports the guest knows of. It works as a teaching case for extension authors and core contributors. - **Funding models:** - Pay-per-use autoscaling shifts hosting cost toward revenue peaks (Black Friday), which suits merchants whose income tracks traffic. - It also makes monthly cost less predictable than fixed plans. ### 🧠 Learning Styles Assessment - **Reading level estimate:** Flesch-Kincaid grade 6.0, Flesch Reading Ease 78.7, computed on the 5,116-word auto-caption transcript with 343 caption-punctuated sentences. Caption punctuation splits speech into short sentences, so the score understates the concept load: terms like PHP workers, traces, Kubernetes, and HPOS go undefined. #### 👀 Visual learners - **Present:** Not assessed. I have the transcript only, so I can't describe the video's visuals. - **Improve:** - A before/after request-flow diagram (cached request vs. post-add-to-cart request) would show the core mechanism. - A table of HPOS's four tables versus `wp_posts`/`wp_postmeta` would show the migration. #### 🔊 Aural learners - **Present:** The episode itself is a 29:20 audio conversation. - **Improve:** A 3-minute audio summary covering the three bottlenecks (cart state, bot crawls, slow code paths) would serve listeners who skip the vendor segment. #### 🗣️ Verbal learners - **Present:** - The guest uses examples: a 400,000-product catalog, a $100/month hosting anecdote, Black Friday traffic. - The host uses an AWS pay-per-use comparison. - **Improve:** Define HPOS on first mention (captions render it "HPS" and never expand it), plus PHP workers, traces, and autoscaling. #### 🧩 Kinesthetic learners - **Present:** None. No hands-on steps. - **Improve:** A lab: install WooCommerce on a local site, enable a page cache, add to cart, and inspect response headers against WooCommerce's cookie list. #### 🧠 Logical learners - **Present:** The guest gives a causal chain (add to cart → uncacheable → more origin load → more servers) and variables that change hosting needs (orders, average order value, ad traffic). - **Improve:** A decision tree: catalog size under 500 → rely on cache; churning catalog → speed up page generation; spiky traffic → autoscale. #### 🧑‍🤝‍🧑 Social learners - **Present:** A two-person interview. The guest invites contact on WordPress Slack and WooCommerce Slack. - **Improve:** A discussion prompt for a WooCommerce meetup: "What cookie does your store set on first load, and why?" #### 🧘‍♀️ Solitary learners - **Present:** None. - **Improve:** A self-check: list your store's active plugins, mark which set cookies for anonymous visitors, and test homepage cacheability. #### 🌿 Naturalistic learners - **Present:** None explicit. - **Improve:** Tie autoscaling to resource use. Scaling servers down off-peak cuts idle compute, and caching bot requests avoids regenerating pages. Measure both as CPU-hours saved. ### 📊 Accessibility Assessment #### Screen reader semantics - Not applicable to this source. It's an audio/video interview, and I didn't audit the episode page's or player's markup. #### Keyboard navigation - Not applicable to this source. I didn't test the player or episode page with a keyboard. #### Contrast and readability - Not applicable to this source. I didn't evaluate visual contrast from a transcript. #### Text resizing and reflow - Not applicable to this source. I didn't test the episode page at 200% zoom. #### Media and captions - **Present:** YouTube auto-captions exist; this analysis uses them. - **Gaps:** - The captions garble the company name ("Urmi AI," "Aroomi," "a roomi," "Do me," "dorume.ai") and the core project name ("HPS" for HPOS). They also render Automattic as "Automatic," Brian Coords as "Brian Cordes," and Claude as "Cloud." - A caption reader gets the wrong product names, which maps to WCAG 2.2 SC 1.2.2 Captions (Prerecorded), where accuracy matters for equivalence. - **Improve:** - Publish human-corrected captions and a downloadable transcript. - I didn't verify whether the episode page offers a transcript. My fetch returned show notes and links only. #### Forms and interactions - Not applicable to this source. The episode involves no forms. The guest mentions an email signup on urumi.ai, which I didn't audit. #### Standards reference - **SC 1.2.2 Captions (Prerecorded), Level A:** auto-caption errors on proper nouns and product names. - **SC 1.2.1 Audio-only and Video-only (Prerecorded), Level A:** applies to the audio podcast feed if no transcript accompanies it (unverified). - **SC 3.1.4 Abbreviations, Level AAA:** beyond the AA target, but relevant since HPOS is never expanded. ### 🌍 DEIB Assessment #### Cultural breadth - **Present:** Examples are US-retail-centric (Black Friday, Meta ads, Shopify and BigCommerce as comparisons). Stores and merchants outside that frame get no mention. - **Improve:** Name peak events from other markets (Singles' Day, Diwali sales) when discussing traffic spikes. #### Inclusive language - **Present:** No exclusionary language. The guest's "inversion of blame" framing explicitly declines to fault non-technical merchants. - **Improve:** Define jargon (PHP workers, traces, Kubernetes, HPOS) for the merchant audience the episode addresses. #### Neurodiversity support - **Present:** The transcript has no segment headings. I can't verify whether YouTube chapters exist. - **Improve:** Add chapter markers at the topic shifts listed in Notes (HPOS 1:47, caching 10:06, bots 13:22, AI operations 16:34, updates 23:28). #### Representation - **Present:** Two speakers: a podcast host and a hosting-company founder. No merchant, plugin author, or independent performance engineer speaks, so merchants' experience arrives secondhand. - **Improve:** Invite a merchant or a plugin author affected by HPOS for a follow-up. #### Psychological safety - **Present:** The guest names merchants' fear of the update button (24:21) and designs around it. The HPOS "inversion of blame" principle removes merchant fault from rollout failures. - **Improve:** Pair the "no update button" model with a way for merchants to see and control what the AI changed, so safety doesn't come at the cost of visibility. ### ✅ Logical Validity #### Strong reasoning - **Causal mechanism, 10:06–11:10:** - The claim that cart state defeats page caching names a mechanism (per-visitor output, session cookies) that WooCommerce's caching guide confirms with specific pages and cookie names. - Clarify further by stating which cookie triggers the bypass on a given cache. - **Qualified generalization, 12:20:** - After the $1M-per-year-on-$100-hosting anecdote, the guest lists the variables that change the result (order count, average order value, ad traffic, organic traffic). - That keeps the claim from reading as a guarantee. - **Consistent timeline, 5:50–6:37:** - The "1 year to build, 1 more to default" estimate fits the public record: January 2022 plan, 7.1 opt-in, October 2023 default in 8.2. - **Scoped claim, 13:22:** - The guest bounds "caching handles bots" by catalog size (100–500 products) and names the case where it fails (100,000 products changing daily). #### Fallacies - **Appeal to popularity (bandwagon), 20:06.** - Weakness: popularity doesn't show that Kubernetes autoscaling suits WooCommerce's stateful database and session layer, and "it can scale to whatever you want it to" has no bound. - Fix: cite a load test (orders per minute, p95 checkout latency) under autoscaling, and name the database strategy. > [!quote] ID:rw_01m2g440kwg30wntb4n19e6r07 > But it's like really a really really popular way to scale this thing, right? Everyone uses it. - **False dichotomy, 8:04.** - The guest contrasts closed-source platforms, with data fragmented across third-party apps, against open source, where the AI "has all the data" (25:48). - Weakness: WooCommerce stores also keep data off-server in payment gateways, analytics, and email tools. Urumi's own homepage advertises Analytics AI that queries "live store, GA, Stripe." - Fix: say open source exposes the application code and database, while third-party service data still needs API access on either platform. - **Unfalsifiable conditional prediction, 26:52–27:36.** - "if things are done right in next 5 years open source based e-commerce platforms like WooCommerce would absolutely dominate the market." - Weakness: "if things are done right" lets any outcome confirm the claim, and no market-share baseline appears. - Fix: give a current share figure, a target, and the adoption conditions that would count as "done right." - **Anecdotal evidence, 11:41 and 25:48.** The $1M-per-year store and the "billions in revenue" customer carry no names, dates, or published data in the episode. - Fix: link the case study and state traffic and order volume alongside hosting cost. - **Unsupported attribution, 9:03.** - The aside that an existing host wants merchants to migrate to BigCommerce assigns a motive to an unnamed party. - Fix: name the source or drop the aside. #### Tone of voice - **Guest:** - Enthusiastic and conversational. Many "right?" tags and superlatives: "one of the biggest change that we will see in our career" (7:34), "open source is one of the most powerful ideas of our generation" (16:34). - Personal on UX: "Update button is something I also have like really personal grudges with" (23:52). - **Host:** - Supportive and practical. Grounds the conversation in client work ("running several WooCommerce sites for clients," 6:37) and billing analogies. - Doesn't challenge the vendor claims. ### 🛡️ DARVO Analysis - **Deny:** - No accusation is under discussion, so no denial pattern applies. - The episode frames the scaling limit as a "myth." That's a rebuttal of a market narrative, not a denial of wrongdoing. - **Attack:** None. The guest doesn't discredit any critic. The only adversarial aside is the unnamed "existing host" that allegedly pushes merchants to BigCommerce (9:03), a motive attribution without evidence, not a personal attack. - **Reverse victim/offender:** None. - **Related note:** The "inversion of blame" principle (4:23) runs opposite to a blame-shifting pattern, since it assigns rollout failures to the project team instead of to merchants. The episode's main rhetorical risk is commercial interest: the host introduces the guest as Urumi's CEO, the guest presents that company's product as the solution, and the host doesn't ask for evidence behind the product claims. ## 🎯 Conclusion - **Bottom line:** - WooCommerce's scaling problems in this episode come from specific mechanisms: cart and session state that bypass page caches, bot crawls that outgrow cache capacity on churning catalogs, and slow code paths. HPOS already removed the order-storage bottleneck, per WooCommerce's own benchmark. - The guest's AI-operations and 5-year market claims are vendor statements without evidence in the episode. - **Next steps for readers:** - Audit your store's cache exclusions and cookies against WooCommerce's caching guide. - Confirm HPOS is on, and check whether compatibility sync is still needed. - Before handing updates to any automated system, ask how you'll see what it changed and how you can force a security update. ## 🔄 Refactor Appendix — Let's Debunk the WooCommerce Scaling Myth ### 📚 Literature Atoms #### [H1] Rollout failures belong to the project, not merchants > [!quote] ID:rw_01m2g43dye79pqnpvft83y1avm > If something goes wrong, we cannot blame the operator of the site, which is often the merchant **Context & use**: - 4:23, describing the principle behind the HPOS rollout (upgrade parties, sync mode, warnings). - Reusable as a design rule for any WordPress core or plugin migration that non-technical site owners trigger with one setting. **Tags**: #xref #aphorisms **Highlight**: [view highlight](https://read.readwise.io/read/01m2g43dye79pqnpvft83y1avm) <!-- atomicity: 1 idea ✓ --> #### [H2] Add-to-cart makes WooCommerce requests uncacheable > [!quote] ID:rw_01m2g43kc9gb078drgz1k9sz5c > With WooCommerce, for example, once you add something to the cart, it's that request cannot be cached anymore, right? **Context & use**: - 10:36, the guest's main explanation of why WooCommerce loads servers harder than a plain WordPress site. - WooCommerce's caching guide confirms the mechanism with its excluded pages and cookie list. Use it in Hosting team and Support team checklists. **Tags**: #xref #share **Highlight**: [view highlight](https://read.readwise.io/read/01m2g43kc9gb078drgz1k9sz5c) <!-- atomicity: 1 idea ✓ --> #### [H3] Catalog churn outgrows cache capacity under bot crawls > [!quote] ID:rw_01m2g43pwqc9qyk5kjv14ygbys > they have like, you know, 400,000 products. They cycle through 100,000 products every day. **Context & use**: - 13:46, a customer anecdote (unverified) showing where caching stops absorbing crawler load. - Useful evidence for Core Performance discussions on uncached render time. **Tags**: #xref **Highlight**: [view highlight](https://read.readwise.io/read/01m2g43pwqc9qyk5kjv14ygbys) <!-- atomicity: 1 idea ✓ --> #### [H4] One broken update teaches merchants to stop updating > [!quote] ID:rw_01m2g43v5zsfweg97vbawg5brx > Merchant wouldn't know that, you know, they would see an update button, they will click it, something will break. **Context & use**: - 24:21, the guest's case for removing the update button on hosted production sites. - Supports a merchant-facing safe-update guide for Documentation and Training. **Tags**: #xref #articleseed **Highlight**: [view highlight](https://read.readwise.io/read/01m2g43v5zsfweg97vbawg5brx) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates #### [P1] Migration safety comes from the maintainer absorbing the blame **Claim** (one sentence, Courtney's voice): A breaking change reaches non-technical site owners safely only when the maintainers treat any breakage as their own bug and fund the outreach, fallback sync, and warnings that prevent it. **Evidence pointer**: [[#H1]] **Scope & conditions**: - Holds for opt-in changes where one site owner's click can break third-party code (HPOS, database schema changes, API deprecations). - Weakens for security fixes that can't wait for a 2-year compatibility runway. **Links**: - [[Backward compatibility in WordPress]] — because extends - [[Release party testing]] — because applies-in plugin and core migration outreach - [[Blameless postmortems]] — because contrasts on timing (before release, not after an incident) <!-- atomicity: 1 idea ✓ --> #### [P2] Update fear is learned from a single failure **Claim** (one sentence, Courtney's voice): A site owner who breaks a site once with an update learns to delay every update after it, security patches included. **Evidence pointer**: [[#H4]] **Scope & conditions**: - Holds for owners without staging or rollback. - Counterexample: owners with automatic backups and one-click restore may keep updating after a failure. - The episode offers this as observation, not measured data. **Links**: - [[WordPress auto-updates]] — because applies-in plugin and theme update UX - [[Merchant documentation]] — because extends `proof_state: working` **Tests / falsifiers**: - Compare update lag before and after a site's first update-related outage across a sample of hosted sites. - No lag increase would refute the claim. <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Find the woocommerce.com scaling case study the guest cites at 25:48 and check its numbers — https://woocommerce.com/posts/can-woocommerce-stores-scale-truth-about-large-stores-with-examples/ #fleeting #inbox - [F2] Resolve the Urumi co-founder discrepancy (Urumi site lists Naman Malhotra; a Repository article summary named someone else, article returned 403) — https://urumi.ai/ #fleeting #inbox - [F3] Check Cloudflare Radar or similar public data for a bot-to-human request ratio to compare with the guest's 1:5 to 1:10 — episode 15:25 #fleeting #inbox - [F4] Look for a public HPOS rollout retrospective (upgrade parties, compatibility sync) to cite in a DevRel talk — https://developer.woocommerce.com/docs/features/high-performance-order-storage/ #fleeting #inbox ### → Things 3 - [ ] Outline a merchant-facing safe-plugin-update checklist (backup, staging, conflict test, rollback) — from the WP Minute episode with Vedanshu Jain, 24:21 #things - [ ] Draft talk abstract "Inversion of blame" comparing the HPOS rollout with a WordPress core migration — episode 4:23, HPOS docs #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Let’s Debunk the WooCommerce Scaling Myth.md|Let’s Debunk the WooCommerce Scaling Myth by WP Minute Podcasts]] ## Highlights - [4:23] And then the interface was simple enough ultimately that people were able to use it. Uh uh like people were like the merchants were able to use it. I think the biggest um the biggest like the principle like the underlying principle we worked on was this inversion of blame, right? If something goes wrong, we cannot blame the operator of the site, which is often the merchant, that, you know, hey, you should not click on this setting, right? Hey, you should have read the doc, right? Hey, you should have done your research before doing this, right? [4:55] Because that sort of, you know, like removes all the responsibility. Instead, the approach that we went for was this inversion, which means that we reached out to as many third-party developers as we can to upgrade our plugins. We released within this like upgrade parties where we invited people to like, you know, upgrade their plugin with us. And we, including me, my teammates, they would provide real-time support for these plugin authors to upgrade their plugins, answer their questions, be available all the time. ([View Highlight](https://read.readwise.io/read/01m2g43dye79pqnpvft83y1avm)) - Note: Inversion of blame: the HPOS rollout put the burden on the WooCommerce team (outreach, upgrade parties, docs, sync mode) instead of on merchants. - Tags: atom/literature/h1, atom/zettel/z1 - [10:06] >> Right. So, with WooCommerce, you can go like really far on a on a simple hosting, like just to be honest. Um so, the main bottleneck with WooCommerce is that you will have lot more requests reaching your servers than a WordPress site, right? So, the main way that people handle um like scaling WordPress site is caching, right? So, you put a cache in front of your site, so most of the requests would be served by cache. They do not need to generate all the data, right? [10:36] With WooCommerce, for example, once you add something to the cart, it's that request cannot be cached anymore, right? Because like the homepage is changed, right? The like the like how it renders changed, right? Which means that lot more requests that would have been handled by cache now have to be answered by your server. Going even further, sometimes the homepage itself cannot be cached based on the plugins that you're using, based on the maybe you're setting a session cookie, maybe you're setting a session for the users. In which case, even the homepage like a fresh render can not also be cached, right? ([View Highlight](https://read.readwise.io/read/01m2g43kc9gb078drgz1k9sz5c)) - Note: Main WooCommerce bottleneck per guest: cart/session state makes requests uncacheable. WooCommerce docs list woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_ as cache-bypass cookies. - Tags: atom/literature/h2 - [13:22] >> Right. So, um So, for the bot traffic, like uh So, first off, caching can most definitely deal with bot traffic. The only problem is a bot is going to like go through pretty much all your products, right? So, if you have like 100, 200 products, caching would generally be able to cache all the pages, like, it would generally be able to cache all the dynamic pages. [13:46] So, like, the traffic doesn't reach you, right? But, for example, for one of our customers, they have like, you know, 400,000 products. They cycle through 100,000 products every day. There's like, you know, being decommissioned, adding new, and so on. Then bot tries to like enumerate all the new 100,000 products because it wants to index it. And then, like, you know, your your caching will go for a toss, right? ([View Highlight](https://read.readwise.io/read/01m2g43pwqc9qyk5kjv14ygbys)) - Note: Bot crawls defeat caching once catalog churn exceeds cache capacity (guest anecdote: 400,000 products, 100,000 cycled daily; unverified). - Tags: atom/literature/h3 - [20:06] But it's like really a really really popular way to scale this thing, right? Everyone uses it. And that's what we do, too. It's not You know, it's not something like weird that we are doing. It's just that if you configure your systems that way, WooCommerce WooCommerce at the end of the day is just another PHP application. And it can scale to whatever you want it to. >> Yeah, so that that kind of reminds me of just, you know, the the old AWS type thing where, you know, you're just paying for what you're using instead of just, you know, I'm I'm paying my server company $1,000 a month [20:39] for this massive uh grid here instead of, you know, just paying as for what I need when I need it. So, like, you know, Black Friday and things like that, maybe I'm paying a little more, but I'm also making more because I'm getting more traffic. >> Yes. So, and if you get traffic, like if you are getting orders, you really don't mind paying for more servers, right? ([View Highlight](https://read.readwise.io/read/01m2g440kwg30wntb4n19e6r07)) - Note: Appeal to popularity: "Everyone uses it" stands in for evidence that Kubernetes autoscaling fits WooCommerce's stateful database and session layer. "Scale to whatever you want" is unqualified. - Tags: fallacy/appeal-to-popularity - [23:52] Sometimes it will ask you if the changes are major, it will ask you to take a look at it as well. But as much as possible, it will try to do it itself, like itself, right? Update button is something I also have like really personal grudges with, if that makes sense. I think that's like not a great experience for merchants. And you know, you know, you maintain your client side, right? You can update, you know how to do this, you know, plugin conflict test, you know how to know when to update and when to wait, right? [24:21] Merchant wouldn't know that, you know, they would see an update button, they will click it, something will break. And once something is break on update, next time onwards they will always be stressed, right? They will they will always be this like fearful of, you know, clicking that button. Which is not great because an update could have security issue, security patches, it could have performance patches. You do want that. ([View Highlight](https://read.readwise.io/read/01m2g43v5zsfweg97vbawg5brx)) - Note: Action: one broken update teaches merchants to skip security patches. Documentation/Training/Hosting angle: a merchant-facing safe-update guide (staging, backup, conflict test, rollback). - Tags: action/h1