Initial situation: an online store on WordPress 6.x + WooCommerce 8.x running on a VPS (Ubuntu 22.04, Nginx, PHP 8.2, MariaDB). Catalog of about 25,000 products and 60,000 variations. Now the exchange with 1C takes place through an outdated module, products are periodically duplicated, prices and balances drop, and during peak hours (sales) order processing is slow and sometimes gives 502. Delivery is calculated through the SDEK plugin, but some orders are sent without the selected pick-up point due to races when recalculating the cart. We need systematic analysis and configuration, without changing the CMS and without completely reworking the theme. Technical environment and restrictions: you cannot stop sales for more than 10 minutes at a time, all changes via staging and Git, deployment via SSH. You cannot connect external SaaS caches like Cloudflare APO; you can use Redis on a VPS. You cannot change the current payment module and URL structure. Pointed code edits are acceptable in the form of a small MU-plugin or your own plugin, without editing the core of WordPress and WooCommerce. What to do: 1) Conduct an audit of the current performance configuration and ordering logic - profiling slow queries (Query Monitor/New Relic or equivalent), analyzing PHP-FPM/Nginx logs, identifying bottlenecks in the database (indexes, slow queries WooCommerce lookup tables, wp_postmeta). 2) Set up caching and stability - enable and correctly configure Redis Object Cache, exceptions for dynamic pages (cart, checkout, personal account), configure page cache on Nginx or correctly configure the existing cache plugin so that prices, coupons and delivery recalculation do not break. 3) Put the exchange with 1C in order - stabilize the import of goods, prices and balances so that duplicates are not created and connections of variations are not lost. Configure mapping by external identifier (SKU/UUID), processing of deleted products, integrity control after import. Add an import log with clear errors (in wp-content/uploads/logs or in a table), without outputting sensitive data. 4) Fix the SDEK pickup point selection script - fix the problem when, when recalculating the cart, the selected pickup point is reset or does not fall into the order. The result should be saved in the order as meta and displayed in the admin panel and emails. If the current plugin does not provide the necessary hooks, make it via WooCommerce hooks without breaking the plugin's updateability. 5) Set up monitoring and protections - enable log rotation, configure alerts to 5xx (sending by email is enough), add a health-check endpoint to check the availability of key components (DB, Redis, wp-cron). Specific result: - Placing an order consistently proceeds without 502 and without losing the selected pickup point. - Import from 1C ceases to create duplicate goods and variations; balances and prices after exchange coincide with unloading. - The site can withstand peak loads without sudden degradation due to correct caching. Measurable acceptance criteria: - P95 checkout page response time - no more than 2.5 seconds with 20 simultaneous users on staging (k6 or analogue), without 5xx. - After a complete exchange with 1C, the number of products and variations does not increase due to duplicates, 0 new duplicates by SKU/external UUID. - In 50 test orders in a row, the selected SDEK pickup point is always saved and displayed in the admin panel and in a letter to the client. - Redis cache hit rate on typical catalog pages is not lower than 70% (according to plugin/redis info metrics), while the cart and checkout are not cached as a page. Expected stages: setting up staging and collecting diagnostics - work and risk plan - implementing caching - fixing 1C exchange - fixing SDEK - load testing - final deployment and checklist. Access and materials: I will provide SSH for staging and production, a database dump for local analysis upon request, access to the WP admin panel, examples of 1C upload (XML) and several problematic orders for reproduction.