The Journey to Build the New Service 'Honeytem' (Wait, By Next Month?) - Part 1

The Honeytem Feed service, which started after Big Smile Day, began from the idea of expanding GBT, an employee-recommended product page, into a customer- and community-facing service. The core concepts of the service were organized around an amusement-park motif: Attraction, Ride (corresponding to posts), and Passenger (referring to users), and the project was named G-world, meaning Gmarket's amusement park.

For scalability, naming was redesigned from the ground up. Under Attraction, features such as content posted by employees and customers, Linkrew integration, product categories, likes, reports, comments, hashtag filters, and merging of duplicate Rides were considered, and content quality management included terms-of-service agreement, post-then-monitor policy, and a reporting flow.

For DB design, given that stored data volume is not large but data integrity is important, Oracle was chosen. Tables were built around ATTRACTION, RIDE, and PASSENGER as the core, and column abbreviations followed in-house metadata standards such as ATRC. Since Attraction could expand to include special promotions, product reviews, corners, and more, categories were separated into their own table, and the design was built with normalization in mind to make structural expansion easier.

On the Ride side, tables were set up for product linkage, recommendations, reports, and comments. It was restricted so that only products with a purchase history tagged during the BSD period could be pulled in as Ride Goods, and purchase-based tags such as first purchase timing or repurchase count were also devised to increase review reliability.

The most challenging part was the Passenger design. Because Gmarket, Auction, and Admin each have different member identification systems, and there are also ID duplication issues, a logical relationship was created by combining user ID, member identifier, and site type. No personal information was stored—only G-world-specific identifiers were managed—and per the DA guideline that Insert Operator and Update Operator should contain system information rather than user information, these were separated out as common columns.

Finally, physical and logical ERDs were created, a subject area was applied for, and a POC was proposed to the team lead and the planning/design teams. With the May BSD rollout confirmed, planning, design, publishing, development, and QA all had to be completed within a month, and during that time team members reinforced the tables and columns, completing G-world's database. The next part will cover the overall Data Flow and tech stack.