Smart Store Center successfully migrated its legacy platform from Oracle to MySQL to overcome performance instability caused by resource contention and to reduce high licensing costs. By implementing a "dual write" strategy, the team achieved a zero-downtime transition while maintaining the ability to roll back immediately without data loss. This technical journey highlights the use of proxy data sources and transaction synchronization to ensure data integrity across disparate database environments.
## Zero-Downtime Migration via Dual Writing
* The migration strategy relied on "dual writing," where all Create, Update, and Delete (CUD) operations are performed on both the legacy Oracle and the new MySQL databases.
* In the pre-migration phase, Oracle served as the primary source for all traffic while MySQL recorded writes in the background to build a synchronized state.
* Once data was fully migrated and verified, the primary traffic was shifted to MySQL, with background writes continuing to Oracle to allow for an instantaneous rollback if performance issues occurred.
* This approach decoupled the database switch from application deployment, providing a safety net against critical failures that a simple redeploy could not fix.
## Technical Implementation for JPA
* To capture and replicate queries, the team utilized the `datasource-proxy` library, which allowed them to intercept Oracle queries and execute them against a separate MySQL DataSource.
* To prevent MySQL write failures from impacting the primary Oracle transactions, writes to the secondary database were managed using `TransactionSynchronizationManager`.
* By executing MySQL queries during the `afterCommit` phase, the team ensured that the primary service remained stable even if the secondary database encountered errors or performance bottlenecks.
* The transition required modifying JPA Entity configurations, such as changing primary key generation from Oracle Sequences to MySQL’s `IDENTITY` (auto-increment) and adjusting `columnDefinition` for types like `text`, `longtext`, and `decimal`.
## Centralized MyBatis Strategy
* To avoid modifying thousands of business logic points in a 10-year-old codebase, the team sought a way to implement dual writing for MyBatis at the architectural level.
* The implementation focused on the MyBatis `Configuration` and `MappedStatement` objects to capture SQL execution without requiring manual updates to individual repository interfaces.
* This centralized approach maintained the purity of the business logic and ensured that the dual-write logic could be easily removed once the migration was fully stabilized.
For organizations managing large-scale legacy migrations, the dual-write pattern combined with asynchronous transaction synchronization is a highly recommended safety mechanism. Prioritizing the isolation of secondary database failures ensures that the user experience remains unaffected while technical validation is performed in real-time.
The integration of AI Briefing (AIB) into Naver Search has led to a noticeable increase in Largest Contentful Paint (LCP) values, with p95 metrics rising to approximately 3.1 seconds. This shift is primarily driven by the architectural mismatch between traditional performance metrics and the dynamic, streaming nature of AI chat interfaces. The analysis concludes that while AIB appears to degrade performance on paper, the delay is largely a result of how browsers measure rendering in incremental UI patterns.
### Impact of AIB on Search Performance
* Since the introduction of AIB’s chat-based UI in July 2025, LCP p95 has moved beyond the 2.5-second target, showing a direct correlation with AIB traffic volume.
* The performance degradation is characterized by a "tail" effect, where a higher percentage of users fall into slower LCP buckets despite stable server response times.
* Unlike Google’s AI Overview, which renders in larger blocks, Naver’s AIB uses word-by-word animations and frequent UI updates that place a heavier burden on the browser's rendering engine.
### Client-Side Rendering Bottlenecks
* Performance profiling indicates that the delay is localized to the client-side rendering phase rather than the network or server.
* Initial rendering includes a skeleton UI period of roughly 900ms, followed by sequential text animations that push the final paint time back.
* Comparative data shows that when AIB is the LCP candidate, the p75 value reaches 4.5 seconds—significantly slower than other heavy components like map modules.
### Structural Misalignment with LCP Measurement
* **DOM Reconstruction:** After text animations finish, AIB rebuilds the DOM to enable citation highlighting and hover interactions, which triggers Chromium to update the LCP timestamp to this much later point.
* **Candidate Fragmentation:** Streaming text at the word level prevents the browser from identifying a single large text block; instead, small, insignificant fragments are often incorrectly selected as the LCP candidate.
* **Paint Invalidation:** Chromium’s rendering pipeline treats every new word in a streaming response as a layer update, causing repeated paint invalidations that push the `renderTime` forward frame-by-frame until the entire message is complete.
### New Metrics for AI-Driven Interfaces
* To more accurately reflect user experience, Naver is shifting toward Time to First Token (TTFT) as a primary metric for AIB, focusing on how quickly the first meaningful response appears.
* Standard LCP remains a valid quality indicator for static search results, but it is no longer treated as a universal benchmark for interactive AI components.
* Future performance management will involve more granular distribution analysis and "predictive" performance modeling rather than simply optimizing for a single threshold like the 2.5-second LCP mark.
To effectively manage performance in the era of generative AI, organizations should move away from relying solely on LCP for streaming interfaces. Implementing TTFT as a complementary metric provides a better representation of perceived speed, while optimizing the timing of DOM reconstructions can prevent unnecessary measurement delays in Chromium-based browsers.
Naver’s Logiss platform, responsible for processing tens of billions of daily logs, evolved its architecture to overcome systemic inefficiencies in resource utilization and deployment stability. By transitioning from a rigid, single-topology structure to an intelligent, multi-topology pipeline, the team achieved zero-downtime deployments and optimized infrastructure costs. These enhancements ensure that critical business data is prioritized during traffic surges while minimizing redundant storage for search-optimized indices.
### Limitations of the Legacy Pipeline
* **Deployment Disruptions:** The previous single-topology setup in Apache Storm lacked a "swap" feature, requiring a total shutdown for updates and causing 3–8 minute processing lags during every deployment.
* **Resource Inefficiency:** Infrastructure was provisioned based on daytime peak loads, which are five times higher than nighttime traffic, resulting in significant underutilization during off-peak hours.
* **Indiscriminate Processing:** During traffic spikes or hardware failures, the system treated all logs equally, causing critical service logs to be delayed alongside low-priority telemetry.
* **Storage Redundancy:** Data was stored at 100% volume in both real-time search (OpenSearch) and long-term storage (Landing Zones), even when sampled data would have sufficed for search purposes.
### Transitioning to Multi-Topology and Subscribe Mode
* **Custom Storm Client:** The team modified `storm-kafka-client` 2.3.0 to revert from the default `assign` mode back to the `subscribe` mode for Kafka partition management.
* **Partition Rebalancing:** While `assign` mode is standard in Storm 2.x, it prevents multiple topologies from sharing a consumer group without duplication; the custom `subscribe` implementation allows Kafka to manage rebalancing across multiple topologies.
* **Zero-Downtime Deployments:** This architectural shift enables rolling updates and canary deployments by allowing new topologies to join the consumer group and take over partitions without stopping the entire pipeline.
### Intelligent Traffic Steering and Sampling
* **Dynamic Throughput Control:** The "Traffic-Controller" (Storm topology) monitors downstream load and diverts excess non-critical traffic to a secondary "retry" path, protecting the stability of the main pipeline.
* **Tiered Log Prioritization:** The system identifies critical business logs to ensure they bypass bottlenecks, while less urgent logs are queued for post-processing during traffic surges.
* **Storage Optimization via Sampling:** Logiss now supports per-destination sampling rates, allowing the system to send 100% of data to long-term Landing Zones while only indexing a representative sample in OpenSearch, significantly reducing indexing overhead and storage costs.
### Results and Recommendations
The implementation of an intelligent log pipeline demonstrates that modifying core open-source components, such as the Storm-Kafka client, can be a viable path to achieving specific architectural goals like zero-downtime deployment. For high-volume platforms, moving away from a "one-size-fits-all" processing model toward a priority-aware and sampling-capable pipeline is essential for balancing operational costs with system reliability. Organizations should evaluate whether their real-time search requirements truly necessitate 100% data ingestion or if sampling can provide the necessary insights at a fraction of the cost.
The integration of AI into the frontend development workflow is transforming how markup is generated, shifting the developer's role from manual coding to system orchestration. By leveraging Naver Financial’s robust design system—comprised of standardized design tokens and components—developers can use AI to automate the translation of Figma designs into functional code. This evolution suggests a future where the efficiency of UI implementation is dictated by the maturity of the underlying design system and the precision of AI instructions.
### Foundations of the Naver Financial Design System
* The system is built on "Design Tokens," which serve as the smallest units of design, such as colors, typography, and spacing, ensuring consistency across all platforms.
* Pre-defined components act as the primary building blocks for the UI, allowing the AI to reference established patterns rather than generating arbitrary styles.
* The philosophy of "knowing your system" is emphasized as a prerequisite; AI effectiveness is directly proportional to how well-structured the design assets and code libraries are.
### Automating Markup with Code Connect and AI
* Figma's "Code Connect" is utilized to bridge the gap between design files and the actual codebase, providing a source of truth for how components should be implemented.
* Specific "Instructions" or prompts are developed to guide the AI in mapping Figma properties to specific React component props and design system logic.
* This approach enables the transition from "drawing" UI to "declaring" it, where the AI interprets the design intent and outputs code that adheres to the organization’s technical standards.
### Challenges and Limitations in Real-World Development
* While AI-generated markup provides a strong starting point, it often requires manual intervention for complex business logic, state management, and edge-case handling.
* Maintaining the "Instruction" set requires ongoing effort to ensure the AI stays updated with the latest changes in the component library.
* Developers must transition into a "reviewer" role, as the AI can still struggle with the specific context of a feature or integration with legacy code structures.
The path to fully automated frontend development requires a highly mature design system as its backbone. For teams looking to adopt this paradigm, the priority should be standardizing design tokens and component interfaces; only then can AI effectively reduce the "last mile" of markup work and allow developers to focus on higher-level architectural challenges.
