Release Notes
New feature additions and improvements
Security Patch
1. Next.js Version Update
Technology stack upgrade: To address the Next.js WebSocket SSRF vulnerability (CVE-2026-44578, CVSS 8.6 High), Next.js has been unified and upgraded to 16.2.11 across all frontend repositories, resolving the security vulnerability.
Key Details
Next.js: 16.2.x > 16.2.11 — 4 repositories in the FO/BO 16.x series (low-risk patch upgrade)
Next.js: 15.x > 16.2.11 — 2 publishing repositories (accompanied by a 15 → 16 major upgrade)
Version unification across all frontend repositories (6 total) — prevents future security patches from being missed due to version discrepancies between repositories
Scope of Impact
All repositories self-hosting via the built-in Node.js server through
next startare affected by the vulnerability, and were upgraded in bulk without exceptionApplication priority: applied sequentially in the order internet-exposed FO → BO → publishing
No changes to business logic, screens, or API specifications
Feature Addition
1. Waiting Queue System Built
A Virtual Waiting Room feature has been added. During traffic spikes such as flash openings and time sales, legitimate users who crowd in are queued and admitted in order, absorbing traffic without service disruption.
Previously, the system only handled this with the gateway's per-IP request limiting (429 rejection) and circuit breakers, which could block bot traffic or bursts from a single source, but crowds of legitimate users arriving from many different IPs still flowed straight through to the backend. This release addresses the gap where the only options were "reject or degrade performance," with neither total-volume control nor a waiting UX.
Key Details
1. Page-Level Queue
Entry to specific product/event pages is queued by waiting token, admitting users in batches according to a configured processing rate. Waiting users are shown a queue screen displaying their position.
Total admission volume is controlled via an "N people per second" processing-rate scheme (
RATE_BASED) — target pages and processing rates are configured via the admin APIProtection-target determination is done at the data level (which product/event is the target), not the URL level, allowing selective queueing even within the same URL pattern
A two-tier structure — SSE real-time updates for the front of the queue and server-driven polling further back — suppresses connection load during large-scale waits
Entry tokens (JWT) are validated locally on the front end, so no extra round trip occurs on each page entry
2. Site-Wide Queue (Automatic Activation)
Even for unplanned overload situations, infrastructure risk indicators are detected and all new inbound traffic to the entire site is automatically placed into a queue.
Monitoring alerts and gateway inflow detection are used to classify risk level as NORMAL / WARN / CRITICAL, and the site-wide queue is automatically activated on CRITICAL
Users who were already using the service pass straight through via their gate session — only new inflow is queued, preventing drop-off among active users
Admission rate is automatically adjusted (AIMD) to match the protected backend's measured throughput — raising the admission rate when there is headroom and immediately lowering it when signs of load appear
The risk-detection phase operates in an observation-only capacity and does not directly block requests
3. Rollout and Operation
The queue is separated out as an independent service, so it can be applied or disabled with a single configuration flag — sites where it is not applied show no trace of it
Configuration, history, and runtime state are all stored in Redis (no separate DB), handling second-level high-speed updates without added burden
Multi-pod environments are supported — the admission-processing scheduler runs on a single pod via a leader lock, while admission notifications are propagated to all instances via Pub/Sub
Fail-open handling ensures the service is not blocked if the queue itself fails
Expected Effects
During flash openings, drops, and time sales, inflow exceeding backend processing capacity is absorbed in order, preventing response delays and errors in core transaction flows such as cart and checkout
The site-wide queue automatically activates even for unforeseen traffic spikes, providing uninterrupted defense
Providing a queue position and waiting screen mitigates user drop-off and retry storms compared to blanket rejection (429)
Improvement
1. TypeScript 6.0.3 Update
Upgraded TypeScript in the X2BEE frontend projects from 5.8.2 → 6.0.3.
Key Details
Reduced build times — 20–50% reduction based on measured cases
Comprehensive cleanup of deprecated settings — cleared out all settings slated for deprecation in 6.0, removing obstacles for the next major upgrade
Uncovered latent type mismatches — stricter checking caught type mismatches that previously passed loosely, explicitly aligning data type consistency
Ensured type safety for third-party CSS imports — added type declarations for side-effect imports and documented them, reusable when introducing similar libraries in the future
Improvement
1. Order afterProcess Redis Streams Adoption
Converted post-order-completion processing (Alimtalk, email) from an in-memory asynchronous approach to Redis Streams-based messaging to prevent loss of post-processing.
Scope: Order-completion Alimtalk, order-completion email
Key Details
Publishing: published directly via XADD after AFTER_COMMIT in api-order's afterProcess (3 retries + exception logging on failure)
Idempotent consumer: duplicate processing prevented via SETNX in-flight lock + DONE flag
Retry/DLQ: isolated to DLQ when deliveryCount > 3, loss prevented via PEL/reclaim
Added monitoring metrics: order_mq_stream_pending (consumer stall), order_mq_dlq_size (immediate alert)
Improvement
1. Display Product Summary Table Improvement
Resolved an issue where instant discounts were not reflected on the display screen because the location where the instant-discount applied price was calculated and stored differed from the location the display screen read from, and made overall improvements to price/discount data consistency.
Key Details
Unified the reference point for instant-discount applied price lookups to the per-site price table (SSOT) — applied consistently across display listings, product detail, brand, search, wishlist, and review screens
Corrected a branching error in fixed-amount vs. percentage-rate promotion calculation logic (fixed amounts were previously miscalculated using the percentage-rate formula)
Added a step to sync bundle-product representative prices to the per-site price table as well
Cleaned up unused instant-discount columns (dead columns) in the main table to separate pricing responsibility
Corrected product display drop-off caused by missing multilingual information (auto-supplemented at load time)
Prevented display of expired instant discounts and cleaned up residual data
Recalculated display status bidirectionally (shown ↔ hidden) based on sale status and period (resold products automatically restored, products converted to unapproved status automatically hidden)
Improved detection logic for wishlist/order-count counter changes, and added a post-load consistency verification step (anomaly logging)
Improvement
1. FO Next.js Shared Cache via Redis (cacheHandler) Applied
The FO (Next.js) cache applied to handle high-volume traffic was previously stored locally on each server (pod), which had limitations in a multi-pod operating environment: cache invalidation upon Backoffice (BO) changes was only applied to the pod(s) that received the request, and a pod's cache would disappear on pod restart or replacement. In this release, the Next.js cache store was switched to shared Redis (a custom cacheHandler), so that all pods share the same cache and changes are consistently reflected across all pods.
Key Details
Switched the Next.js fetch cache store from the pod-local filesystem to shared Redis (custom cacheHandler based on ioredis)
Cache invalidation (revalidateTag) triggered by BO content changes is now immediately reflected across all pods — previously, it was applied only to the single pod that received the request, leaving other pods showing older data for some time
Cache is preserved in Redis even during pod restarts, redeployments, and autoscaling, allowing the service to start warm without a cold start
Applied graceful degradation that bypasses the cache and calls the origin directly if Redis fails — ensuring a cache-layer failure does not lead to a service outage
Separated dedicated Redis DB indexes per environment to isolate this from other data such as backend cache and sessions
2. Virtual Thread Adoption (Backend Performance Improvement)
Applied Virtual Threads to backend APIs on the Java 21 + Spring Boot 4 stack. Tomcat request-processing threads and asynchronous (@Async) tasks now run as virtual threads, reducing thread pool exhaustion and boosting throughput under high concurrency without any application code changes.
Key Details
Converted request-processing and asynchronous task threads to virtual threads across 8 backend API services (common, backoffice, product, order, display, member, integration, event) (configuration-based application, no behavior or spec changes)
Threads are released rather than held during I/O waits such as DB and external API calls, allowing a small number of threads to handle a large volume of concurrent requests and mitigating delays/errors caused by thread pool exhaustion
Proactively inspected all backend modules for thread pinning sections that could undermine the performance benefits of virtual threads, and improved the identified spot (the settlement receipt module)
Applied as a zero-downtime drop-in with no changes to existing business logic, screens, or API specifications
Improvement
1. Backend API N+1 Query Pattern Improvement
Converted repeated in-loop DB query (N+1) patterns for multi-data lookups into batch queries using IN clauses to reduce API response time, and removed parallelStream to eliminate the risk of DB connection pool exhaustion.
Key Details
Converted repeated queries that occurred proportional to the number of reviews N when viewing the review list in My Page into batch queries using IN clauses
Converted repeated queries that occurred proportional to the number of cart items N into batch queries using IN clauses
Converted a structure where parallelStream simultaneously occupied DB connections when querying zone-based products on the planned-exhibition detail page into a single batch query
Converted delivery info, button, and product info lookups that were repeatedly called proportional to the number of orders N — in order list, received gift box, and subscription-delivery detail views — into batch processing
Improved a structure that repeatedly called the DB and external product API proportional to the number of events N when viewing event participation history, switching it to a pre-batch query approach
Converted sequence numbering that was issued per record when saving mileage registration history into batch numbering
Improvement
1. Google Analytics (GA) Integration
In this release, the existing Umami-based analytics structure was removed and replaced with a Google Analytics (GA)-based analytics framework. FO user behavior events were improved to be collected using the standard GA event structure, and the BO statistics screens and batch structure were also rebuilt on the GA Data API, providing a more accurate and scalable data analytics environment.
Improvement
1. BO/PO Single-Item Creation Feature Improvement
Extended the feature so users can directly enter options when registering a product, and improved it to save that option information for reuse.
Key Details
Added a "Create New Option" button — allows direct entry of option name/option value
Added an "Option Info Save" button — saves the selected newly created option information
Target Screens
(BO/PO) Products > Product Management > Product Registration
(BO/PO) Products > Product Management > Manage Saved Drafts > Edit Product
2. OPEN-API Single-Item Save Feature Improvement
Improved so that single-item information composed of options directly entered by the user during product registration is saved, and that option information is stored for reuse.
Key Details
Single-item information including directly entered options is saved when calling the product registration API
Added the optnSaveYn parameter to provide a feature that saves directly entered option information
Improvement
FO Loading UI Fix
Replaced the PulseLoader spinner (...) previously shown during data loading across all FO (Front Office) pages with a shimmer-animation skeleton UI.
Key Details
Implemented a common skeleton component (CornerSkeleton) and shimmer CSS
Replaced the loading UI for corner sections / dynamic corners
Replaced skeletons for display areas (planned exhibitions, ranking zones)
Replaced skeletons for common UI components (ProductList, BannerSlide, etc.)
Replaced skeletons for product detail areas (Q&A, package, review tab)
Fixed a scroll drift bug
Re-fixed the shimmer single-sweep effect (two white lines → single)
Added a skeleton for the product detail review tab
X2BEE 3.2 update
Modernized the platform technology stack with an upgrade from Spring Boot 3.3.4 → 4.0.3, Java 17 → 21, and Jakarta EE 9 → 11.
1. Spring Boot 4.0.3 Upgrade
Performed a major version upgrade from Spring Boot 3.3.4 to 4.0.3. Modernized the platform technology stack by converting Java 17 → 21 (LTS), Spring Framework 6.x → 7.x, and Jakarta EE 9 → 11, laying the groundwork for long-term security support and use of the latest features such as Java 21 Virtual Threads.
Key Details
Spring Boot 3.3.4 → 4.0.3 (Spring Framework 6.x → 7.x)
Java 17 → Java 21 (LTS)
Jakarta EE 9 → Jakarta EE 11 (javax.* → jakarta.* package conversion complete)
Spring Cloud 2024.0.x → 2025.1.0 Oakwood
Spring Batch 5 → 6 (BatchConfig, JobConfig, Tasklet migration)
Hibernate 6 → 7 (hibernate-types → hyperpersistence-utils dependency conversion)
x2bee-common 0.9.918 → 0.9.919 (Jakarta EE 11 support, changed ObjectMapper auto-injection method)
Expected Effects
Laid the groundwork for improved throughput via Java 21 Virtual Thread support
Benefits from long-term security patches and technical support on the latest LTS
Access to the latest features in the Spring ecosystem (AOT, GraalVM Native, etc.)
Technology Stack Upgrade
Next.js 16.0.10 → 16.2.3 upgrade: incorporated the latest security patches and Turbopack performance improvements, and resolved build issues arising from stricter build rules.
1. Next.js Version Upgrade
Upgraded the Next.js version from 16.0.10 → 16.2.3 and adjusted the source code to comply with the stricter Turbopack build rules introduced in 16.1.0. Also resolved a Server Action compilation error caused by an incorrectly declared 'use server' directive, along with a package internal-path-reference blocking issue arising from the switch to moduleResolution=bundler, together securing compatibility with the latest build environment and stability of production builds.
Key Details
Next.js: 16.0.10 → 16.2.3
eslint-config-next: 16.0.1 → 16.2.3
Removed an incorrectly declared Server Action directive
Fixed a package internal-path-reference blocking issue
Expected Effects
Incorporates the latest version's security patches and Turbopack performance improvements
Secures compatibility with the latest build environment and stability of production builds
Improved initial load speed and build performance
Improvement
Product Detail SEO Optimization: added an input section to the BO so operators can directly manage SEO information per product, and improved the FO product detail page to automatically reflect meta information and JSON-LD structured data.
1. Added Product Detail SEO Optimization Feature
Added an input section to the BO so operators can directly manage SEO information per product, and improved the FO product detail page to automatically reflect meta information and JSON-LD structured data.
Continued → — releases from 2026-04-17 to 2026-04-10.