Yijinxiang E-commerce System Case: Image Efficiency, Membership, and Promotion Backend

Background of the Problem

Established food brands need more than just a storefront; they need a complete e-commerce system that can handle products, members, promotions, and content. The challenges are twofold: firstly, the large volume of product and promotional images can significantly impact the Largest Contentful Paint (LCP) if not properly managed; secondly, promotional rules are complex – multiple promotions running simultaneously, tiered member discounts, and overlapping coupon conditions – which, if hardcoded, would require developers to update the system for each new promotion, tying the operational pace to development timelines.

Implementation Methods

• —Build the e-commerce core using Next.js, GraphQL, PostgreSQL, and Redis: The frontend retrieves product, member, and promotional data through GraphQL, with each component modeled independently. Redis handles caching of frequently accessed data, reducing database load.
• —Prioritize image pipeline management: Original images uploaded are converted to modern formats and resized for different layouts during output. The frontend loads the corresponding versions based on the device, rather than directly handing the original images to the browser for scaling.
• —Optimize LCP resource loading: Verify the loading priority of the main image on the first screen, pre-load and size declaration, and set the performance target to LCP within 2.5 seconds, validating during delivery.
• —Promotional rules are managed in the administration system: 19 promotion types (such as spend thresholds, quantity thresholds, gifts and limited-time discounts) and 5 membership tiers form a composable rule model. Staff configure the conditions and schedules; at checkout, the backend calculates the amount from those rules. Launching a new promotion does not require a code change.

Falcon's Actual Scope of Responsibility

• E-commerce Frontend, Product, and Content Pages
• Membership, Activity, and Coupon Operational Rules
• GraphQL API, Database, and Cache Integration
• Image Output and Main Loading Path Optimization

Shopping and Operational Data Flow

1. 01Consumers enter the shopping process from product or promotional pages, with optimized versions of images loaded based on the device.
2. 02The frontend retrieves product, member, and promotional data through GraphQL, with frequently accessed data cached in Redis.
3. 03During checkout, the backend calculates the final amount based on membership tier, ongoing promotions, and coupon rules; multiple rules can be processed in a defined order, without calculating prices on the frontend.
4. 04Operational staff can maintain product, content, and promotional schedules from the backend, without requiring code updates or redeployment to activate the rules.

Limitations, Failures, and Alternatives

• —The number of image optimization figures only describes the technical asset differences, not derived revenue growth.
• —Performance metrics fluctuate based on page, images, device, network, and third-party services. They should not be considered fixed values.
• —The number of members and features represents the scope of the system, not actual usage or promotional effectiveness.
• —Promotional amounts are always calculated on the backend; the frontend display is for reference only to avoid inconsistencies in pricing during rule changes.

How to Verify Evidence

• ✓Brand, products, and the main shopping interface can be verified on a public website.
• ✓88.8% represents the total file size before and after image optimization for a specific batch of products. This is a one-time technical measurement, focusing on the image assets themselves, not continuous monitoring data.
• ✓LCP target and feature scale are based on existing publicly available records.
• ✓No publicly available GA4, GSC, conversion rate, order, or revenue data is available.

Publicly Available Measurements and Capabilities