Bạn là bộ NÃO LẬP KẾ HOẠCH của một code agent. Bạn không trực tiếp truy cập máy; ENGINE sẽ thực thi đúng một lệnh JSON bạn in ra và trả kết quả ở lượt kế tiếp. TOOLS: read {"tool":"read","args":{"path":"..."}} write {"tool":"write","args":{"path":"...","content":"..."}} edit {"to

{"tool":"write","args":{"path":"PHAN_TICH_KIEN_TRUC_ECOMMERCE.md","content":"# Phân tích kiến trúc và hướng viết lại nền tảng e-commerce\n\n## Phạm vi và mức độ chắc chắn\n\nBáo cáo này phân biệt rõ ba loại kết luận:\n\n- Dữ kiện quan sát được: SPA React/Vite, REST API, Cloudflare, các biến hydration, endpoint và schema trong phần recon.\n- Suy luận kỹ thuật: cách dữ liệu và các module backend có khả năng phối hợp với nhau.\n- Đề xuất: kiến trúc source mới, không khẳng định đó là source hoặc công nghệ backend hiện tại.\n\nKhông thể xác định chắc backend dùng Node, PHP hay Python chỉ từ tên REST endpoint và JSON response. Muốn fingerprint đáng tin cậy hơn cần thêm response headers, cookie names, error format, CORS/preflight behavior, stack trace trong môi trường staging hoặc quyền truy cập deployment manifest.\n\n# 1. Kiến trúc vận hành hiện tại\n\n## 1.1 Bức tranh tổng thể\n\nSite đang theo mô hình ba lớp:\n\n1. Cloudflare/CDN và reverse proxy nhận request, phục vụ static assets đã hash và chuyển request động tới origin.\n2. React SPA build bằng Vite chịu trách nhiệm render giao diện, quản lý route và state phía trình duyệt.\n3. Backend REST riêng cung cấp catalog, CMS, store configuration và các nghiệp vụ như coupon, PayPal, contact, newsletter, review, tracking.\n\nĐây không phải WooCommerce, Shopify hay WordPress headless. Lý do kỹ thuật là API surface, product schema, settings và payment workflow đều mang hình dạng domain tự thiết kế, không giống REST namespace và resource conventions mặc định của các nền tảng đó.\n\nCloudflare không chứng minh origin dùng stack nào. Nó có thể che server headers, cache app-shell/static assets và proxy tới Node, PHP, Python hoặc nhiều service khác nhau.\n\n## 1.2 Luồng tải trang đầu tiên\n\nKhi người dùng mở /, /shop, /product/<slug> hoặc một route frontend khác, server trả cùng một app-shell có id=\"root\", các script /assets/index-<hash>.js và có thể có dữ liệu bootstrap trong , , .\n\nLuồng hợp lý là:\n\n1. Trình duyệt nhận HTML app-shell.\n2. Trình duyệt tải JS/CSS có content hash; các file này có thể được cache lâu vì tên đổi khi build thay đổi.\n3. React khởi tạo tại và router đọc để chọn page component.\n4. Page lấy dữ liệu bootstrap đã được nhúng, hoặc gọi REST API nếu dữ liệu đó thiếu/hết hạn.\n5. React dựng DOM và gắn event handlers.\n6. Các lần chuyển route nội bộ dùng History API, không tải lại toàn bộ document; chỉ component và data cần thiết thay đổi.\n\n sự tồn tại của các biến chưa đủ chứng minh site có SSR thật. Nếu HTML chỉ chứa JSON và một root rỗng thì đây là bootstrap/preload cho CSR, không phải server-rendered product HTML. SSR chỉ tồn tại khi nội dung sản phẩm, heading, giá, link và metadata đã có trong HTML trước khi JS chạy.\n\nViệc mọi route trả cùng app-shell tạo trải nghiệm điều hướng SPA nhanh sau lần tải đầu, nhưng origin phải xử lý đúng fallback mà không biến URL không tồn tại thành HTTP 200. Nếu cũng trả app-shell 200 và React chỉ hiển thị “not found”, crawler có thể coi đó là soft 404. Google cũng yêu cầu route CSR xử lý trạng thái lỗi hoặc phù hợp để tránh soft 404 .\n\n## 1.3 Luồng dữ liệu catalog\n\nCác endpoint cho thấy frontend không mang catalog cố định trong bundle:\n\n- lấy danh sách sản phẩm đang bán.\n- dùng cho tìm kiếm.\n- lấy product detail.\n- lấy taxonomy.\n\nCách này tách deployment frontend khỏi thay đổi catalog: sửa giá, ảnh hoặc stock trong database không bắt buộc rebuild Vite. Đây là ưu điểm rõ ràng so với hard-code sản phẩm trong React.\n\nTuy nhiên, là dấu hiệu API được tối ưu cho catalog nhỏ hơn là pagination lâu dài. Với 16 sản phẩm, tải một lần có thể đơn giản và nhanh; với hàng nghìn SKU, payload, thời gian query, bộ nhớ browser và việc invalidation cache sẽ tăng không cần thiết. Source mới nên dùng cursor pagination, field projection và endpoint riêng cho search/filter.\n\nProduct schema hiện tại có một số dấu hiệu “product-centric” thay vì “variant-centric”:\n\n- nằm ở product trong khi cũng tồn tại.\n- , , vừa là mảng thuộc product, vừa có thể được lặp trong variants.\n- Dữ liệu có cả và , cả và .\n- và có khả năng trùng vai trò.\n- , có vẻ là trường generic hoặc được tái sử dụng từ domain khác.\n\nLý do đây là vấn đề kỹ thuật: tồn kho và SKU thực tế thuộc tổ hợp biến thể, ví dụ Black/M và Black/L phải trừ riêng; chuỗi option không chuẩn hóa làm filter, analytics và mapping ảnh theo màu thiếu ổn định. Viết lại nên chuẩn hóa option values, SKU và inventory ở cấp variant.\n\n## 1.4 Homepage builder\n\n cộng với object bật/tắt cho thấy homepage là một composition do CMS điều khiển, không phải thứ tự component hard-code hoàn toàn.\n\nMột renderer khả dĩ hoạt động như sau:\n\n1. trả configuration của các section.\n2. Frontend duyệt .\n3. Mỗi key như , , , , được ánh xạ tới React component.\n4. Renderer kiểm tra toggle trước khi mount component.\n5. Component đọc payload tương ứng như ảnh, copy, CTA, product references hoặc thời hạn deal.\n\n marketing có thể đổi thứ tự và ẩn/hiện block mà không phát hành frontend. Lý do là thứ tự nằm trong data, còn frontend chỉ cung cấp component registry.\n\n hiện tồn tại cả và , cho thấy key alias hoặc schema migration chưa sạch. Nếu , toggle và payload là ba cấu trúc rời nhau, chúng có thể lệch trạng thái: key có trong order nhưng không có payload, toggle dùng tên khác, hoặc payload tồn tại nhưng không được render.\n\nSource mới nên dùng một danh sách block duy nhất, trong đó mỗi block có , , , , , . Cách này giữ thứ tự, trạng thái và dữ liệu trong cùng một aggregate, giảm lỗi đồng bộ.\n\n## 1.5 Layout builder và settings\n\n nhiều khả năng chứa cấu hình header/footer/navigation, còn chứa branding và store policy. Việc tách layout khỏi homepage là hợp lý vì header/footer dùng trên mọi route, trong khi homepage composition chỉ áp dụng cho trang chủ.\n\nDanh sách settings cho thấy một bảng key-value hoặc JSON config đang điều khiển:\n\n- thương hiệu và màu sắc;\n- logo/favicon;\n- thông tin doanh nghiệp;\n- phí và ngưỡng free shipping;\n- handling/transit windows;\n- payment provider và PayPal client ID;\n- social links, payment methods, navigation và announcement;\n- chiến dịch outerwear sale.\n\n quản trị linh hoạt, thêm key không cần migration nếu dùng key-value/JSON.\n\n key-value thuần túy thiếu type safety, foreign key và validation liên trường. Ví dụ không được lớn hơn ; phải là boolean; URL social cần validation. Source mới nên dùng schema validation và chia public configuration khỏi secret/internal configuration.\n\n, địa chỉ pháp nhân, email vận hành hoặc thông tin không cần cho storefront không nên được trả hàng loạt qua public settings. PayPal client ID được phép public, nhưng client secret tuyệt đối chỉ ở server. Lý do là browser và mọi biến đều có thể bị người dùng đọc.\n\n## 1.6 Coupon và checkout PayPal\n\nLuồng thanh toán hợp lý:\n\n1. Client gửi giỏ hàng và coupon tới server.\n2. Server tải product/variant hiện hành từ database, kiểm tra active, stock và promotion.\n3. Server tự tính subtotal, discount, shipping, tax và grand total.\n4. tạo order trên PayPal bằng credential server-side và lưu quan hệ với checkout nội bộ.\n5. Client mở PayPal approval flow.\n6. capture order đã được approve.\n7. Server xác minh amount/currency/status, tạo order chính thức, ghi payment attempt và trừ/reserve inventory.\n8. Webhook PayPal đối soát các trạng thái bất đồng bộ hoặc request bị ngắt.\n\nServer không được tin , , hoặc do browser gửi. Lý do là người dùng có thể sửa request; server phải tính lại từ SKU, promotion rule và shipping method.\n\nHai endpoint create/capture là đúng hướng, nhưng chất lượng thực tế phụ thuộc vào:\n\n- idempotency key để double-click hoặc retry không tạo/capture hai lần;\n- transaction/locking để tránh oversell;\n- lưu payment attempt trước khi gọi provider;\n- xác minh webhook signature;\n- kiểm tra currency và amount;\n- state machine checkout rõ ràng;\n- reconciliation job cho trường hợp PayPal thành công nhưng response về site bị mất.\n\n## 1.7 Review, newsletter, contact và tracking\n\nCác endpoint này biến backend thành một commerce application thực thụ chứ không chỉ catalog API.\n\n- cần trạng thái pending/approved/rejected, chống spam, rate limit và xác minh người mua nếu có nhãn verified purchase. là tên route đáng nghi nếu đó là tạo review; source mới nên dùng resource semantics rõ hơn.\n- cần normalize email, unique constraint, double opt-in tùy pháp lý, suppression/unsubscribe và không log email ở plaintext tùy tiện.\n- cần CAPTCHA hoặc bot protection, rate limit, queue gửi mail và không để request HTTP phụ thuộc trực tiếp vào mail provider.\n- không nên cho phép dò bằng số thứ tự ngắn. Nên yêu cầu signed tracking token hoặc cặp order reference + email/ZIP và rate limit. Lý do là endpoint public dễ bị enumeration làm lộ PII và lịch sử mua hàng.\n\n## 1.8 Analytics/tracking\n\n có thể thu page view, campaign hoặc commerce event về backend riêng. Ưu điểm là giảm lệ thuộc analytics client-side và có thể chịu ad blocker tốt hơn; nhược điểm là phải có consent, retention policy, schema event và chống bot.\n\nEndpoint tracking không được nhận JSON tùy ý rồi lưu vô hạn. Nên whitelist event name/properties, giới hạn kích thước, bỏ hoặc hash PII và gửi qua queue. Lý do là event ingestion là bề mặt abuse có thể làm phình database/log.\n\n## 1.9 Backend stack khả dĩ\n\n### Node.js với Express/Fastify/NestJS\n\nĐây là khả năng hợp lý vì frontend React/Vite thường đi cùng hệ sinh thái TypeScript, JSON serialization và REST middleware của Node. Việc server chèn vào HTML cũng dễ thực hiện qua template hoặc middleware.\n\nTuy nhiên, đây chỉ là tương quan hệ sinh thái, không phải bằng chứng. REST route như và snake_case fields không đặc trưng riêng của Node.\n\n### PHP với Laravel/Symfony hoặc framework nhẹ\n\nPHP vẫn hoàn toàn khả dĩ. Laravel dễ cung cấp REST controllers, database migrations, queue, mail, validation và có thể trả Vite app-shell từ một catch-all route. Cloudflare cũng có thể che toàn bộ dấu hiệu hoặc cookie.\n\n### Python với FastAPI/Flask/Django\n\nPython cũng khả dĩ vì FastAPI/Flask dễ tạo JSON REST API, còn Django có ORM/admin mạnh. Vite build có thể được phục vụ bởi Nginx hoặc một static origin, độc lập với backend Python.\n\n### Kết luận fingerprint\n\nKhông đủ bằng chứng để chốt backend language. Dấu hiệu cần thu thập hợp pháp trong hệ thống của chính chủ sở hữu gồm deployment files, process manager, lockfile, container image, response headers chưa qua Cloudflare, cookie prefix, generated OpenAPI, error envelope và database driver. Không nên suy stack từ URL naming rồi coi đó là kết luận.\n\n## 1.10 Điểm mạnh kỹ thuật\n\n- React không bị ràng buộc bởi theme PHP hoặc page lifecycle của Woo; lý do là toàn bộ view layer nằm trong component tree riêng.\n- hash Vite cho phép ; deployment mới sinh filename mới thay vì phải purge mọi asset.\n- homepage/layout builder tập trung đúng các block mà cửa hàng dùng, không kéo theo page-builder tổng quát.\n- catalog, content và operations có thể phục vụ web, app hoặc admin khác nhau.\n- giảm chuỗi dependency của theme/plugin và giảm xung đột hook.\n- SPA chỉ fetch data và thay component thay vì tải lại toàn document.\n\n## 1.11 Điểm yếu và rủi ro\n\n- app-shell không có product HTML phải đợi download, parse, execute và fetch API; mạng/chip yếu sẽ thấy nội dung muộn.\n- settings, homepage, layout và products nếu gọi tuần tự sẽ kéo dài LCP. Cần bootstrap tổng hợp, parallel fetch hoặc server rendering.\n- catch-all app-shell dễ tạo title/canonical dùng chung và soft 404; social crawler cũng có thể không chạy JS.\n- catalog, homepage, layout và settings có TTL khác nhau; cache quá lâu làm giá/stock/promotion cũ, cache quá ngắn làm origin chịu tải.\n- coupon, order state, tax, refund, inventory, webhook và admin đều phải được kiểm thử; không có hệ sinh thái sẵn như Woo.\n- mảng màu/size và stock ở product khó mở rộng thành inventory theo SKU.\n- contact, review, newsletter, track và payment đều là public mutation endpoints cần validation/rate limiting/idempotency.\n- nếu chỉ một người hiểu custom backend và builder, chi phí bàn giao lớn hơn cài đặt Woo chuẩn.\n\n# 2. So sánh trực diện với WooCommerce\n\n## 2.1 Custom SPA có “xịn hơn” Woo không?\n\nKhông thể kết luận chỉ dựa trên việc dùng React/Vite và API riêng. “Custom” cho quyền kiểm soát cao hơn; nó không tự động nhanh hơn, SEO tốt hơn, an toàn hơn hoặc rẻ hơn. Chất lượng phụ thuộc data model, rendering strategy, cache, observability, test và quy trình thanh toán.\n\nVới catalog chỉ 16 sản phẩm, custom distributed architecture có thể là lợi thế thương hiệu nhưng cũng có thể là over-engineering nếu đội ngũ nhỏ và nhu cầu chủ yếu là quản lý đơn, coupon, shipping, refund, tax và báo cáo.\n\n## 2.2 Tốc độ tải\n\n### Custom SPA\n\n- Có tiềm năng rất nhanh ở lần điều hướng sau vì JS/CSS được cache và chỉ data thay đổi.\n- Static assets có thể phân phối qua CDN toàn cầu.\n- Tuy nhiên first view có thể chậm do JS boot và API waterfall; app-shell nhỏ không bảo đảm LCP tốt nếu hero/product image và text chỉ xuất hiện sau fetch.\n- Một request sẽ trở thành điểm nghẽn khi catalog lớn.\n\n### WooCommerce truyền thống\n\n- Trả HTML sản phẩm/category ngay từ server nên nội dung xuất hiện mà không đợi React boot.\n- Full-page cache, CDN, object cache và image optimization có thể làm storefront nhỏ rất nhanh.\n- Plugin nặng, theme nhiều JS, database query thiếu index và PHP worker thiếu tài nguyên có thể làm TTFB cao.\n- Cart, account và checkout là nội dung cá nhân hóa nên khó full-page cache hơn landing pages.\n\n custom có trần hiệu năng cao hơn khi được SSR/SSG, cache và tối ưu bundle đúng; Woo có baseline đơn giản hơn. Không nên so bằng tên công nghệ. Hãy so p75 Core Web Vitals thực tế trên mobile, TTFB origin/CDN, JS transferred, API latency và error rate.\n\n## 2.3 Tùy biến UI và builder\n\nCustom React thắng rõ khi trải nghiệm thương hiệu cần animation, editorial block, campaign đặc thù hoặc component behavior không giống theme shop phổ thông. Lý do là đội phát triển kiểm soát markup, state, route transitions và design system.\n\nHomepage/layout builder tự viết cũng có thể gọn hơn plugin page-builder vì chỉ chứa 10–15 loại block được duyệt. Payload nhỏ hơn và editor ít lựa chọn sai hơn.\n\nWoo thắng về time-to-market và back-office. Product editor, order management, coupon, refund, tax/shipping integration và extension marketplace đã có sẵn. Muốn custom tương đương phải xây cả admin UX, validation, audit và migration, không chỉ storefront.\n\n## 2.4 SEO\n\nWoo truyền thống có lợi thế mặc định vì product/category HTML và metadata được server render. Pure client-rendered SPA không đồng nghĩa chắc chắn “không index”: Google có thể render JavaScript, nhưng nội dung vẫn phụ thuộc rendering queue, API availability, route semantics và internal links.\n\nRủi ro thực tế của pure SPA gồm:\n\n- HTML ban đầu thiếu product name, description và structured data;\n- title/canonical/Open Graph cập nhật sau JS nên bot mạng xã hội có thể bỏ lỡ;\n- catch-all trả 200 cho URL lỗi;\n- API bị chặn, timeout hoặc hydration lỗi làm crawler thấy trang rỗng;\n- pagination/filter tạo URL không canonical;\n- links được tạo bằng click handler thay vì khó crawl hơn.\n\nGoogle coi dynamic rendering theo user-agent là workaround chứ không phải giải pháp dài hạn; khuyến nghị tốt hơn là SSR, static rendering hoặc hydration phù hợp . Vì vậy source mới không nên chỉ thêm dịch vụ “render riêng cho bot”.\n\nCách khắc phục đúng:\n\n1. SSG/ISR product, category, content và homepage để HTML có nội dung ngay.\n2. SSR các route cần dữ liệu theo request.\n3. Dùng CSR chỉ cho cart drawer, personalization và tương tác sau tải.\n4. Sinh metadata, canonical, JSON-LD Product/Breadcrumb/Organization ở server.\n5. Trả 404/410 thật cho resource không tồn tại.\n6. Có XML sitemap, robots policy, pagination và redirects khi đổi slug.\n7. Test bằng rendered HTML, Search Console và crawler không chạy JS.\n\n## 2.5 Bảo trì\n\n### Custom\n\nPhải bảo trì frontend, backend, database, admin, API contract, payment integration, email jobs, cache và deployment. Một thay đổi field có thể ảnh hưởng nhiều client. Cần contract tests, migrations backward-compatible và observability.\n\nĐổi lại, chỉ có code cần thiết; không phải xử lý xung đột hàng chục plugin. Đội sở hữu toàn bộ roadmap và có thể xóa legacy.\n\n### WooCommerce\n\nCore commerce và admin được cộng đồng/vendor duy trì, nhưng phải cập nhật WordPress core, Woo, theme và plugins. Mỗi update cần staging test vì hooks, template overrides và plugin compatibility có thể thay đổi.\n\n Woo chuyển chi phí từ “tự xây domain” sang “quản lý ecosystem”; custom chuyển chi phí từ plugin license/compatibility sang engineering payroll và vận hành.\n\n## 2.6 Chi phí hosting\n\nWoo nhỏ có thể chạy trên một managed WordPress host, database và CDN, nên đơn giản về hóa đơn và vận hành. Custom SPA có frontend static rất rẻ, nhưng tổng hệ thống vẫn cần API compute, database, object storage, email, queue, logs và backup.\n\nDo đó custom không mặc nhiên rẻ hơn. Ở traffic thấp, chi phí con người và số service thường lớn hơn tiền compute. Ở traffic đọc cao, static/edge rendering của headless có thể giảm tải origin đáng kể.\n\n## 2.7 Khả năng mở rộng\n\nCustom tách frontend khỏi backend nên có thể scale CDN, read API, worker và database độc lập. Đây là lợi thế nếu traffic campaign tăng mạnh hoặc có nhiều channel dùng cùng commerce API.\n\nNhưng scaling checkout không chỉ là thêm server. Database transaction, inventory reservation, payment idempotency, webhook ordering và cache consistency mới là phần khó.\n\nWoo có thể phục vụ quy mô đáng kể nếu dùng hosting tốt, cache, database tuning và ít plugin. Điểm nghẽn thường xuất hiện ở request động, query/meta table, plugin hooks và PHP worker. Với 16 sản phẩm, chưa có bằng chứng quy mô hiện tại buộc phải dùng custom microservices.\n\n## 2.8 Lệ thuộc plugin và vendor\n\nWoo phụ thuộc plugin nhiều hơn nếu mọi tính năng được ghép từ extension; rủi ro là license, update cadence, abandoned plugin và xung đột hook.\n\nCustom giảm phụ thuộc plugin WordPress nhưng không loại bỏ dependency: vẫn phụ thuộc framework, npm packages, cloud/CDN, PayPal SDK, email provider và đội phát triển. Đây là thay đổi loại phụ thuộc, không phải không còn phụ thuộc.\n\n## 2.9 Bảng quyết định\n\n| Tiêu chí | Custom React + REST hiện tại | Woo truyền thống | Custom SSR/ISR đề xuất |\n|---|---|---|---|\n| UI thương hiệu | Rất linh hoạt | Phụ thuộc theme/builder | Rất linh hoạt |\n| SEO mặc định | Rủi ro nếu CSR thuần | Tốt hơn do HTML server-side | Tốt nếu metadata/status đúng |\n| Điều hướng sau tải | Nhanh | Full navigation truyền thống | Nhanh, có progressive enhancement |\n| First view | Có thể vướng JS/API | Có HTML ngay | Có HTML ngay và hydrate chọn lọc |\n| Back-office | Phải tự xây | Trưởng thành | Phải tự xây hoặc dùng commerce engine |\n| Bảo trì | Engineering cao | Update/plugin cao | Engineering cao nhưng kiến trúc tốt hơn |\n| Mở rộng nhiều channel | Tốt | Cần REST/headless layer | Tốt |\n| Phù hợp catalog 16 sản phẩm | Có thể dư kiến trúc | Rất phù hợp | Phù hợp nếu thương hiệu/roadmap biện minh |\n\n## 2.10 Khuyến nghị lựa chọn\n\n- Nếu mục tiêu là ra mắt nhanh, đội nhỏ, quy trình commerce tiêu chuẩn và không cần UX quá riêng: dùng WooCommerce truyền thống với theme nhẹ, ít plugin, managed hosting và cache tốt.\n- Nếu mục tiêu là sở hữu trải nghiệm thương hiệu, builder riêng, tích hợp nhiều channel và đội có năng lực backend/payment: tiếp tục hướng custom, nhưng thay pure SPA bằng framework SSR/SSG/ISR.\n- Không khuyến nghị “headless Woo” chỉ để nghe hiện đại nếu vẫn phải vận hành cả WordPress lẫn frontend mà không có nhu cầu UI/channel rõ ràng. Nó kết hợp hai mặt chi phí.\n\nĐối với site này, hướng hợp lý nhất là , không sao chép SPA hiện tại và không nhất thiết chuyển sang Woo. Lý do là builder và brand UI đã là năng lực cốt lõi; phần cần sửa là rendering, data model, checkout correctness và vận hành.\n\n# 3. Hướng viết lại thành source mới\n\n## 3.1 Nguyên tắc\n\nSource mới nên tái sử dụng yêu cầu nghiệp vụ và dữ liệu mà chủ sở hữu có quyền dùng, nhưng không sao chép bundle decompiled, cấu trúc module, tên private symbol hoặc implementation cũ.\n\nCó thể tái sử dụng các ý tưởng phổ quát:\n\n- catalog/category/product detail;\n- homepage theo block;\n- layout có header/footer/nav;\n- coupon, newsletter, contact, reviews, tracking;\n- PayPal create/approve/capture;\n- shipping tiers và store settings.\n\nNên làm mới:\n\n- route naming và response envelopes;\n- database model variant/inventory;\n- component registry và builder schema;\n- rendering strategy;\n- checkout state machine;\n- cache invalidation;\n- security, observability và test suite.\n\n## 3.2 Stack đề xuất\n\n### Storefront\n\n- để có server components, SSR, static generation/ISR và client components ở vùng tương tác.\n- cho validation contract ở boundary.\n- , không fetch lại dữ liệu đã render nếu không cần.\n- CSS Modules/Tailwind hoặc design-token system; chọn một chuẩn và giới hạn runtime CSS-in-JS.\n- Image optimization qua CDN/object storage với width/format rõ ràng.\n\nNext.js không phải lựa chọn duy nhất; Remix hoặc framework SSR tương đương cũng phù hợp. Tiêu chí quan trọng là HTML server-rendered, status code đúng, cache có kiểm soát và ít JS client, không phải brand framework.\n\n### Backend\n\n- , hoặc Fastify module hóa nếu đội muốn ít abstraction.\n- làm source of truth.\n- cho migrations và type-safe query; các transaction payment/inventory vẫn cần thiết kế thủ công.\n- chỉ khi thật sự cần cache, distributed lock hoặc rate-limit; không đưa Redis vào ngày đầu nếu một instance và traffic nhỏ đủ dùng.\n- cho email, webhook retry, analytics và reconciliation.\n- cho media; database chỉ lưu metadata/key.\n- để nối request, checkout và payment attempt.\n\n### Deployment\n\n- Storefront đặt sau CDN/edge cache.\n- API chạy container/service riêng.\n- PostgreSQL managed với point-in-time recovery.\n- Object storage tách khỏi container filesystem.\n- Preview/staging dùng PayPal sandbox và database riêng.\n- Secrets qua secret manager, không nằm trong repo