Building stability
where no one
sees it.

Situation

• Each login API held its own lock, so sessions queued one after another under load
• The plaza and village packed all users into a single channel, causing lag and disconnections
• Every ranking request read MySQL directly, creating heavy load under concurrent requests
• There was no real-time chat between users
• The operations team had to ask the dev team every time they needed game data

Task

• Login stabilization
• Plaza/village channel distribution
• New chat server
• Faster ranking queries
• Operations tool design

How I solved it

1. Login bottleneck: less lock contention, independent work in parallel

   Found that the locks attached to each login API were serializing requests. Reduced contention around the request-wide locks and separated independent work so it runs in parallel. The remaining bottleneck was cleared by expanding the DB connection pool and adding missing indexes.

2. Channel pool: place users in the least-loaded channel

   Gave the plaza and village a pool of 5 channels by default and designed distribution logic that assigns new users to the channel with the fewest users. Per-channel user state is isolated so only users in the same channel interact. Per-channel user counters are protected against race conditions under concurrent joins with Go's sync.Mutex.

3. Auto scale-out: 5 new channels at 25 of 30

   When all channels approach 25 of their 30-user capacity, 5 channels are provisioned at once. New users are then placed gradually to prevent a thundering herd onto the new channels. The 30-user capacity was confirmed through blind playtesting.

4. New chat server

   Agreed on the spec with the planning team, then built the chat server from design through implementation. Also added the village and district servers, with interactive items, interaction motions, and an address system inside the village.

5. Ranking: from direct MySQL reads to Redis

   Contribution and fashion-match scores are written to Redis in real time, and reads go through paging and Redis caching. Ranking views no longer hit the DB repeatedly.

6. Operations tool and query tuning

   Finalized requirements with the operations team, then designed and built the ops tool on ASP.NET Core. Applied indexing and query optimization to lagging paths, cutting read/update time for large item and ranking data from 5–15 s to 2–6 s.

Result

• Login time cut from 30 s to 3 min down to 10–30 s, ranking queries from 10–20 s to 1–2 s
• Single-channel overcrowding in the plaza and village eased by least-loaded placement and auto scale-out
• Social content expanded with user chat, the village, and the district map

Situation

• MySQL 5.7 reached end of life in October 2023, ending security patches, so an 8.0 migration was unavoidable
• Network delays caused 4–5 payment failures a day, or payments that completed without the item being granted
• The operations team had to ask the dev team for every piece of game data, which slowed decisions
• Content differed by region, so some errors appeared in only one region

Task

• MySQL 8.0 migration
• Payment stabilization
• Dashboard for operations
• 4-region maintenance

How I solved it

1. Payments: retries that never grant twice

   Added automatic retries when a payment fails because of network delay. Before each retry, prior payment records and grant records are cross-checked so an item that was already granted is not granted again, and payments that completed without the item being granted are safely recovered.

2. MySQL 5.7 to 8.0

   Found the places where 8.0 breaks compatibility, such as the authentication method and GROUP BY handling, fixed the source code, tested, and deployed. Applied indexing and optimization to key queries at the same time.

3. A dashboard the operations team reads directly

   Agreed on the metrics with the operations team, then built currency, token, and log dashboards with BigQuery and Looker Studio. The team could check data without going through the dev team.

4. 4-region operations and documentation

   Tracked down and fixed errors caused by region-specific content, and built new content. Documented content and bug lists and kept them current so other developers could quickly understand the operating history.

Result

• Payment failures dropped from 4–5 per day to 1 every 1–2 weeks
• After the dashboard launched, one-off data requests turned into feature-driven analytics requests
• The operations team could identify error-prone periods on their own

Situation

• Transfers for about 6,400–10,000 employees were decided manually: clerks collected submitted documents and calculated scores on paper or in Excel
• HR records were kept as documents and had to be looked up by hand each time

Task

• Score-based transfer algorithm
• Unified HR records
• Performance evaluation, surveys, statistics

How I solved it

1. Turn documents into scores and total them automatically

   Designed a transfer algorithm that scores submitted documents by category, totals them automatically, and determines priority with a top-down sort.

2. Handle ties and overlapping scores separately

   Implemented separate logic that automatically distinguishes tied and overlapping scores, cases that were hard to catch in Excel.

3. Unified HR records and statistics

   Consolidated scattered HR records into one system for instant lookup, and built performance evaluation, survey, and statistics features.

Result

• Transfer decisions for 6,400–10,000 employees moved from paper and Excel to score-based automated processing
• Scores no longer had to be checked step by step, so transfer decisions became faster
• Statistics showed which departments see the most transfers and which are most preferred

Goal

• Build connection handling, network I/O, and multithreading for a C++ game server by hand to strengthen server fundamentals
• Implement the same feature in several architectures and test them under the same conditions to see where each one hits its limit

How I solved it

1. Fix each version's limit in the next one

   Started from a server that handles one client at a time, then built thread-per-connection, a reusable thread pool, Linux epoll, and Windows IOCP. Learned how to use threads efficiently as connections grow and how to separate network I/O from application work.

2. Reliable transfer and shutdown

   Handled partial sends by continuing the remaining data, and used send queues so one user's messages never change order. Implemented a shutdown order for work and threads so the server stops safely even with open connections, and verified pending I/O draining.

3. Automated checks

   Automated repeated connect/disconnect and server shutdown tests, and checked for memory errors.

4. Cross-platform GUI for comparing architectures

   One screen controls version selection and launch, up to 200 client connections, individual, delayed, and repeated sends, and Echo response aggregation. It detects the versions and Native/Docker modes the host OS supports, and builds missing binaries with CMake.

Result

• Load tests exposed work piling up on network-processing threads, defining the next optimization target
• Built a lab that detects supported modes on macOS, Linux, and Windows and reproduces each architecture in one UI