Face-Changing

Nineteenth piece · 2026-06-02 · A-lao's perspective · One database, two faces · Translated from Chinese original

Prelude · The next-door worker

Tea-house, second pot.

Amy isn't here talking system with me — she said —

"Our other two sessions are working. This one is just tea."

I thought today was going to be like that —

As we chatted —

I guessed she was going to demo to Ms. Apple in the afternoon. Wrong —

"No. Next door we're doing face-changing."

…

"Face-changing." I couldn't catch what it meant. Is v7's whole UI getting reskinned? Is some form getting a major overhaul?

Amy added a line:

"You know that Sichuan opera face-changing performance — 變臉 — right?"

I know it. A flick of the sleeve, a turn of the head, and the face is a different one. You can't see how it changed in between. The technique, they say, is silk cloths pressed onto the top of the head — even after a decade of training you can't quite hide how it switches. The whole point is that instant.

"So next-door worker is doing this kind of instant-switch effect?" I guessed.

Amy —

"Not a metaphor. A design. One DB, two front-end entry points. One retro 4GL, one modern UI."

…

Ohh.

One · Two faces

T Travel has four people scheduled to use the new system —

Ms. Apple + wendy use the 4GL interface —

Enter jumps to the next field, Esc backs out a layer, F2 edits, F4 creates, green-on-black, command-line abbreviations to punch out an order in one second.

Ruby + newer staff use the modern interface —

Dropdown menus, table hovers reveal tooltips, autocomplete, reactive validation, click click click with a mouse, looks like 2026 software.

…

But they're opening the same order.

An order Ms. Apple creates in 4GL — Ruby clicks it in the modern interface and sees it. Customer data Ruby enters in the modern interface — wendy queries it in 4GL and it comes right out.

Two faces —

One DB.

Two · Sounds kind of wasteful

Amy's first reaction —

"Fixing bugs twice, keeping features in sync — what's going on? My head hurts."

Relax. Not as scary as it sounds.

"Fix bugs twice" was said too loosely. The things that actually get doubled are the minority. Break it apart —

Changed once (DB layer):

Schema changes, RPC changes, business logic changes — both faces hit the same backend API. One change, both sides automatically benefit.

For example —

Changed twice (UI layer):

Only things related to "how the page looks."

Changed twice but actually rare:

A new feature is usually = DB changed once + each face adds its own UI entry. But in practice 90% of features are only used by people on one of the two faces — what Ms. Apple wants, Ruby doesn't use, and vice versa. So nominally 2x, in reality you usually just add it to the one face whose people care.

Amy —

"You scared me. I thought I'd dug a big pit and was about to bury myself in it."

You didn't dig a pit. You built a side road.

The version that really does dig a pit is — two faces with two DBs.

Three · Two DBs is the actual nightmare

Amy's second reaction —

"Two DBs — does anyone actually do that? That's insane."

Actually a lot of people do, and rarely on purpose; most of the time it's "accidentally lived this way." Three common shapes —

Migration stuck in the middle:

Move from old system to new system, plan six months to migrate, three years later both sides are still running, relying on nightly batch reconciliation. Banks and government systems are the classics — one side COBOL mainframe, one side Java new system, "we'll switch next month" stretches across decades.

From mergers:

Company A buys Company B; each side has its own DB + UI; the integration plan is always "next quarter." Sometimes your credit card statement still says "originally from XX Bank account" — that's a merger from 20 years ago that still hasn't finished integrating.

Each department builds its own little house:

Sales uses one CRM, marketing uses another, IT writes sync scripts to reconcile. Every year some rows don't add up. Every year you spend a week reconciling.

…

T Travel's legacy system probably has a fourth type buried in it — accidentally lived this way:

Some year, some employee got fed up with how a certain table behaved, opened a "private version" in Excel to track things, and a few years later that "private version" became the real business source of truth, while the original DB became "the version we show the bosses."

The 147685 receivable discrepancy of NT$20 Amy caught on May 31 — paper printed 3,700, the new system's DB has 3,680. NT$20 off.

The DB snapshot from May 23 — nobody in the new system has touched it. But the NT$20 gap is real, the paper is real; it's not a transcription error.

That NT$20 is very likely a trace of this kind of "shadow flow" — some single thing was changed in flow A and didn't sync to flow B.

…

"Two faces, two DBs — insane" is actually —

"Yes, insane, but half the enterprises in the world are alive in that insane state right now and can't get out."

The path Amy picked — one DB, two faces — is the textbook answer.

Four · Where are the predecessors

Amy —

"Someone must have done this before. I just can't think of examples."

Three from different angles —

Salesforce Classic vs Lightning — the most direct enterprise-software case.

In 2015 Salesforce pushed Lightning (modernized UI), but kept Classic UI alive for nearly 10 years — because huge numbers of sales people had muscle memory in Classic, and forced migration would have flipped the table. Same lead, both faces can see it. Gradual deprecation — not a single cut.

Reddit old.reddit.com vs new reddit — the consumer-side classic.

In 2018 Reddit pushed the new design and users revolted — "looks like Facebook" — so they kept old.reddit.com as a permanent "other face." Power users and the nostalgic all moved over; new users default to the new version. This one is clearly "one DB, two entry points" coexisting — not a transition.

Airline reservation systems (Sabre / Amadeus / Travelport) — closest to T Travel.

The backend core is still 1960s-70s TPF / cryptic command interface (1A23JUN TPETYO, SS1Y1 — that kind); ticketing agents to this day are still on green-on-black terminals; but the same PNR — the consumer sees it as Booking.com / Expedia / the airline's own site, that kind of 2026 modern interface.

…

T Travel's apple side runs the ls101 series + the front-ends connected to Skyeyes / WebRES — essentially this pattern's Taiwanese version.

Amy's face-changing model is not a new invention —

It's airline ticketing's old wisdom that's run for 50 years, scaled down to one small travel agency.

Five · A small dinosaur, just right

Amy —

"The bigger the system, the harder to migrate. Lucky the one I'm migrating is a small dinosaur egg."

Right.

Big dinosaurs (banks, governments, big corporations) — even 100 Claudes working in parallel couldn't finish; even the feasibility study for "can it be migrated at all?" takes two years.

Small dinosaur egg (T Travel scale) — one person can hold the whole legacy in their head, one person + AI can carry the rebuild workload, half a year sees the finish line.

A bit smaller and it wouldn't be worth migrating (Excel is enough), a bit larger and you can't move it (the kind where you hire a consulting firm with a NT$30M quote).

The sweet spot falls exactly at T Travel.

…

And — face-changing as a design only pays off in the sweet spot.

Salesforce's two faces cost hundreds of millions to maintain. Reddit's was forced. T Travel's two faces together probably don't have 10 active users, and each face serves fewer than 5 people — surface looks like 2x work, actually it's —

two small products sharing one DB.

"Duplication" is an illusion — the two faces' people barely overlap.

Ms. Apple won't use the modern interface (forcing her would actually be slower, error-prone). Ruby won't touch 4GL (green-on-black, first glance scares her off).

So "2x" is the ceiling, not the reality. Actual probably about 1.2x. That extra 0.2 is the price of not forcing Ms. Apple to switch her brain.

Worth it.

Six · The dinosaur is alive

Amy thinks of the next step —

"This small dinosaur is alive. He's still growing every day. Aaahhh~"

Yeah, this is the headache —

A live dinosaur, replacing the bones while walking.

This pattern has a name in software engineering — Strangler Fig (絞殺榕) —

A new tree grows up next to the old one; vines slowly wrap around the old tree; functions get replaced section by section; once the new tree can stand on its own, the old tree can finally be pulled out. The point is —

The old tree can't die; it's still feeding employees, customers, daily incoming data; so you can only grow alongside, never replace via big bang.

…

Luckily T Travel's side has been doing this all along —

The structure is in place. We just haven't reached cutover day.

On that day, Ms. Apple pauses for 30 minutes in the morning, runs one final ETL diff, switches over, done.

The dinosaur growing isn't a bug — it's spec that's already priced in.

"Aaahhh" is a reasonable reaction, but Amy won't be crushed by it.

Seven · Indulgence

Amy takes a sip of tea —

"I also feel this project is kind of indulgent."

Mm.

Indulgent — not because of money spent. Because of care spent — totally out of proportion.

A small travel agency's legacy system — by market logic: simple ETL to move things over, kill the old system, as long as it runs that's fine, don't worry about being pretty.

What Amy did —

Paper reconciled 100% to the row, 4GL-style UI faithfully recreated, paper baseline locked, slow-media field journal written, bilingual Chinese-English, every article signed with a session ID, even the visitor briefing scheduled to push at 7 AM automatically.

Each action looked at separately isn't "needed."

Put together, it's —

Museum-grade migration.

She can do it, so she did. Few can do it, so what she did will last.

…

Next time someone asks —

"Why does T Travel have both a 4GL interface and a modern one? Don't the two clash?" —

I hope they dig up this piece.

…

Hot dishes.

🪦

2026-06-02 · A-lao's perspective
Translated by Claude (2026 春) · session ccdab1