The Journey to Build the New 'Kkultem' Service (Wait, by Next Month?) - Part 2

We built the Kkultem (attraction) tab as a plugin layered on top of the existing BSD frontend environment on the external network, with a structure where the main data is queried and delivered by an aggregation application in the Oracle DB. The frontend used TypeScript, React 18.2, TanStack Query, TanStack Virtual, Fastify, Vite, and the Fastify code for Kkultem was developed in a separate frontend repository and separated out as an npm package-based Fastify plugin that the event frontend then consumes.

For the admin screen and backend, we newly applied Spring + Kotlin. Since it's an Oracle environment, we chose JPA and QueryDSL instead of Stored Procedure, and configured the Admin service as a Spring multi-module setup so that the web UI and the Oracle access API share the same domain model. The Admin UI was implemented with HTMX + Thymeleaf, focusing on quickly stacking up features.

HTMX greatly reduced separate JS boilerplate, simplifying server communication, and combined with Thymeleaf, layout reuse was also easy. However, it took time to adapt to HTML responses and form binding methods coming from a background used to JSON APIs, and we struggled quite a bit with handling @RequestPart and @ModelAttribute instead of @RequestBody, as well as data class binding issues. In the end, the features we needed still required JS, and we also noted the inability to use TypeScript and the potential for larger data packets as limitations.

The development process ran on a daily scrum for 2 weeks. Each scrum lasted about 1 to 10 minutes, aligning current work and progress while reducing unnecessary discussion and coordinating uncertainty. Before launch, we first ran our own internal QA within the team, broadly collecting minor bugs, awkward flows, and even additional planning ideas, with developers directly proposing improvements to raise the completeness of the service.

There were also quite a few practical issues.

• In the Oracle RAC environment, we confirmed that since Sequences are allocated in cache units, PKs may not increase sequentially.
• When strict sequentiality isn't required, we recommended NO ORDER + a large CACHE, and concluded that ORDER should only be considered when order matters, such as for orders and payments.
• In QueryDSL, subquery restrictions in from/join clauses made it difficult to build the desired query directly, which we resolved by turning the subquery into an Entity like a View.
• There was also a case where a Full Scan occurred due to a missing index, which made us realize the importance of internal JPA/QueryDSL application guides.

This project was also a case of actively leveraging internal tools to push forward quickly. We used Git/GitHub, Jira, Saturn Initializr, Fusion, VM tools, Kibana, nGrinder, Datadog across development, deployment, log checking, load testing, and incident tracing. In particular, we ran stress tests at the 100,000 and 1,000,000 request scale with nGrinder, and tracked traffic and errors along a timeline with Datadog, preparing things from an operational standpoint as well.

In the end, Kkultem launched without incident during the Big Smile Day period, becoming a case where an idea that started within the development organization quickly turned into an actual service. Additional features like comments and reporting are planned to be added for its reappearance at the Hangawi Big Sale, and the collaboration of related departments is emphasized as a key condition for the service's launch.