I’m a backend engineer and a digital artist. My work visualizes the power dynamics of technology, such as censorship, attention, and algorithms, turning hidden mechanics into experience.
keyupang.work@gmail.com
Projects
①
2025
②
2025
③
2024
④
2025–2026
Backend and frontend engineering
2025—2026
at Trip.com
Backend engineering for large-scale hotel connectivity systems, including full-stack contributions across backend and frontend
Since 2025, I have worked as a Backend Engineer at Trip.com in the Hotel High Connectivity Group. I work on large-scale backend systems that support hotel operations and merchant platforms, focusing on building stable, scalable services and improving system efficiency.
Currently, I am mainly responsible for the development of tax and fee-related modules, and I also contribute to frontend modifications when needed.
Project 1: FCP partner ecosystem platform
The platform supports Trip.com’s global partner ecosystem by translating complex business objectives into a clear, structured information system. FCP (Favoured Connectivity Partner) refers to direct connectivity partners that are strategically prioritized for collaboration.
The platform aims to expand overseas partnerships, improve visibility of partner capabilities, and streamline communication between Trip.com and its partners. It includes two main components: a program value overview, communicating partner incentives and benefits, and a partner directory, presenting technical capabilities and collaboration scope.
Through information visualization and structured design, the system reduces information asymmetry and enhances the efficiency of overseas collaboration.
Favoured partner detail page
Favoured partner program portal
Project 2: Tax strategy layer
In many jurisdictions, Online Travel Agencies (OTAs) have a collect-and-remit obligation: the OTA collects part of the tax from the guest and pays it directly to the local government instead of settling with the hotel. The platform must therefore flag which taxes are OTA-remitted versus hotel-settled, display tax in a compliant way (e.g., blurred or itemized where the law requires), and apply cancellation and penalty rules that match local and product rules. With many hotels and frequent changes in regulations and policies, doing this by hand is slow and error-prone.
The strategy layer stores these rules and applies them automatically: operators configure once, and the system keeps the right entities up to date with less manual work.
tax strategy configuration edit page, where you set and edit each strategy setting
Architecture
I owned end-to-end development across all five layers: from the frontend tax dashboard (presentation) and backend API (application), through the tax basic information service (business logic and strategy sync triggering), down to the job layer that listens for sync events, selects targets, and applies config, and finally the DAO layer for strategy persistence.
High-level architecture
A listener routes each message to either a full-sync path (selecting targets by rules and enqueueing one task per target) or a single-entity path. In both cases, the actual update is done per entity: load strategies and related data, run a multi-layer rule match, and write the result to downstream config stores in an idempotent way. The design keeps producers and consumers decoupled, scales by processing entities asynchronously, and ensures config is applied consistently for both bulk and incremental triggers.
Message-driven end-to-end flow of tax strategy synchronization
With many entities and many fields to query, we were making too many downstream calls.
Solution
Added a cache system for entity metadata so we don’t repeatedly query the same hotel. Reduced downstream calls by batching: where the API allows it, I request by list of IDs instead of one per ID; for rule and config matching, I load all needed data once per scope, build in-memory maps, and do all matching via local lookup so we don’t call again per entity or per rule
Challenge 2
If processed sequentially in one job, it blocks too long and risks timeouts. If one entity fails, the whole batch may fail or require complex retry logic.
Solution
Introduce a message-driven “select + dispatch” model. The full sync handler only selects in-scope entities and sends one message per entity to a message queue. Workers consume these messages and process each entity independently. If sending or processing one entity fails, it is logged and isolated; other entities continue. This decouples selection from execution, avoids blocking, and allows horizontal scaling of workers.
Challenge 3
With possible failure points and a large number of entities, it becomes hard to see what failed, where, and whether it can be retried.
Solution
Centralized failure logging. On each critical failure, record structured data into a searchable store. Use a stage field to distinguish where the failure occurred. This enables post-hoc analysis, failure-rate monitoring, and targeted retries. The system alerts when failure rates exceed a threshold and produces periodic failure summary reports for follow-up and remediation.