English · 简体中文

I’m Xu Huan (Gelatoni), a software engineer with experience in enterprise HR data systems and cross-border payment products. I work across requirements, domain boundaries, backend implementation, testing, and rollout. My public repositories show independent work; much of my enterprise work is represented here through the problems I handled and the way I approached them, rather than employer-owned source code.

Previous day: 2026-11-06, 00:00–24:00 Asia/Shanghai. Last 30 days: 2026-10-08 through 2026-11-06.

Registered users: 0; enabled alerts: 0.

Registered users: 0.

Interaction tracking started 2026-11-05T01:33:42.493Z (UTC). Unavailable or incomplete periods are shown as “—”.

Subscriber change yesterday: —; snapshot collected: —. Current subscribers: 2 (2026-11-07; collected 2026-11-07 04:06:33 UTC). Yesterday's post: view message.

Subscriber change yesterday: —; snapshot collected: —. Current subscribers: 2 (2026-11-07; collected 2026-11-07 04:06:33 UTC). Yesterday's post: view message.

Websites use Cloudflare Web Analytics; bot activity uses private Telegram aggregate snapshots; channel metrics include subscriber snapshots and publication receipts. Channel post views are not available through the Bot API. Products and metric types are not added together. Scheduled at 08:00 Asia/Shanghai (may be delayed). Definitions and history.

I worked as a backend engineer across recruitment workflows and HR master data. The work covered business rules, data models, service boundaries, and changes to systems with many existing consumers:

• Campus recruitment: worked on configurable resume-assignment rules, including department hierarchy, rule priority, overlapping conditions, and conflict handling. Other work included interview scheduling model changes, batch scheduling, and adapting flows shared by campus and experienced hiring.
• HR master-data migration and APIs: worked on a staged migration involving more than 1,000 legacy interfaces. Compatibility routing, old/new behavior and data comparisons, traffic observation, and recovery planning helped protect upstream callers. I also worked on consolidating overlapping APIs toward roughly 200 domain-level interfaces; that number was a target, not a claim that every old API was retired.
• Employment-plan decoupling: worked on separating business-system input from master-data semantics. This involved tracing how multiple upstream systems generated employment plans and designing the boundaries for timeline calculation, conflict resolution, historical changes, and organization-structure derivation. The source notes include proposals as well as implementation work, so these design areas are not all claims of completed rollout.
• Architecture and reliability: worked on clearer domain, application, and infrastructure boundaries, alongside governance of service dependencies, messaging, scheduled jobs, caching, monitoring, and change safety. These were parts of a broader team program, not a claim that I personally delivered every item in the program.

This experience is most relevant when a client needs to change an established system: understand existing behavior, define ownership and scope, verify the new path, and plan a controlled release. The source code is employer-owned and is not published here.

At a cross-border payments company (2026), I worked on Payment Links, fee and billing capabilities, and account-to-account payout flows. Implementation work visible in local history includes fee-record queries, payout fee allocation, and a merchant billing page. My design notes also trace money and account states across services, distinguish current behavior from proposed behavior, and specify scope, security, idempotency, monitoring, and regression cases.

What this demonstrates: I can clarify a business flow across services and turn it into explicit decisions and verification points. Some documents describe plans, so I do not present every proposed component as a shipped result. Employer-owned code and internal designs are not reproduced here.

1. Clarify the request. Identify the user journey, existing behavior, data ownership, and unresolved decisions.
2. Control the scope. Write down what this release includes, what it leaves for later, and which existing paths must remain compatible.
3. Design for failure as well as success. Account for retries, partial completion, data consistency, rollback, and operational visibility.
4. Verify against the requirement. Derive cases from the original request, then check implementation, regressions, and the running service.
5. Leave a handoff trail. Document decisions, deployment steps, known limits, and follow-up work.

I use AI tools in parts of this workflow, with explicit context and constraints. I keep the judgment on business semantics, data boundaries, and final verification with the engineer responsible for the change.

My writing archive contains engineering notes on migration, stability, product scope, payments, and AI-assisted development. Two starting points are AI-assisted development in practice and stability as a systems and business problem. Some older articles discuss employer systems; I am reviewing which of them should remain public and which should become anonymized case studies.

The enterprise systems used company-specific infrastructure. I describe those tools by their general function; the table does not imply that a named open-source equivalent was used there.

• Master's in Big Data Technology and Engineering, East China Normal University (2020–2023)
• Bachelor's in Computer Science and Technology, East China University of Science and Technology (2016–2020)

• Enterprise case studies: concise, anonymized write-ups showing the starting problem, my exact role, decisions, validation, and what actually shipped.
• Evidence for independent products: screenshots, walkthroughs, and measured outcomes where they can be verified.
• Contact and availability: a direct route for relevant project inquiries and a clearer description of the assignments I take.

For now, you can read the writing, try the live product, or inspect the repositories.