This article was partially machine translated

Not everyone who swipes cards is chasing cashback, and not everyone who designs systems is a programmer. Some swipe cards like designers, and design systems like they live life.

1. Introduction: What is a Card Enthusiast?

Let’s start with something I once saw online—the seven favorite hobbies of card enthusiasts:

Note: “Mainland China” here refers to regions where capital inflow and outflow are restricted.

1. Finding ways to spend foreign currency in China
2. Finding ways to spend RMB abroad
3. Finding ways to move RMB out of the country
4. Finding ways to bring foreign currency in
5. Applying for cards that are useless in China
6. Applying for cards that are even more useless abroad
7. Trying to move around money that doesn’t even reach the length of a typical PIN code, across a bunch of nearly useless cards

Note: In mainland China, bank PINs are usually 6 digits. This is a self-deprecating joke meaning “my balance doesn’t even reach 6 digits, but I’m still shuffling it like it matters.” May not apply elsewhere.

It may sound like a financial game—applying for cards, chasing cashback, reducing fees, optimizing exchanges… Seems like a bunch of petty tricks.

But for true card enthusiasts:

It’s not about saving a few bucks—it’s about designing an optimal, multi-channel, multi-constraint capital flow system.

They’re not milking the system. They’re exploring the architecture of reality, optimizing the structure of everyday life.

2. What Does a System Architect Actually Do?

To become a certified system architect, you need to learn all kinds of jargon—modular decoupling, performance optimization, API specification, and more. But beyond the terms, the real job is simple:

Faced with complex constraints, allocate resources, design routes, and connect systems to build something stable yet flexible.

A system architect isn’t just writing beautiful code or drawing diagrams. Their main concern is: will the system work in real-world chaos? For example:

• How should modules divide responsibilities?
• How should services interact?
• How can interfaces be defined for future expansion?
• How do we locate issues and isolate failures?
• How do we balance performance and cost under limited resources?

Their role is part LEGO builder, part road engineer, part system patcher. Not given a perfect blueprint from the start, they piece things together step-by-step in a broken and messy world.

In short, they design systems that run steadily, adapt quickly, and are affordable to maintain. They don’t chase technical perfection—they chase what works. That’s the beauty of system architecture.

I only learned these things for an exam, but through that process, I rediscovered my passion for card optimization.

3. The “Architecture Problems” of Card Enthusiasts

Card optimization isn’t just “saving a little money.” And system architecture isn’t just “high-end tech design.” Despite different contexts, they both tackle the same core challenge:

Navigating constraints, managing costs, and designing optimal structures in an uncertain world.

Card enthusiasts don’t just apply for cards—they design capital flows.
System architects don’t just code—they design control and data flows.

Card people ask: how do I reduce fees, avoid risk flags, and ensure smooth transactions?
Architects ask: how do I reduce failures, scale up, and maintain stability?

I originally studied architecture for the test, but looking back—it’s the same thinking I used when optimizing my card flows.

Card optimization isn’t exploiting loopholes—it’s designing capital flow architectures.

They aren’t “doing things.” They’re building structures: not just finding the best cashback card, but designing a path that moves funds with minimal cost and maximum efficiency.

They don’t just ask “can it be done,” but “is it elegant.”

Card optimization is solving a constrained shortest-path problem, just like service topology design is about optimizing module coupling under SLA limits.

The difference between them? Just different application domains.

4. System Practice Through Personal Exploration

Others chase cashback. I’m studying the ecosystem.

Every card enthusiast’s path is unique. We each deal with different banks, currencies, and lifestyles.

The fun doesn’t lie in copying others—but in finding your own optimal flow through trial and error, grounded in real context.

I started off just trying to save a little on fees. But after digging through endless documentation, I realized: every bank had its own transfer policies, time windows, restrictions. Some offered free morning transfers, others were fast but limited to specific currencies. Some would randomly block transfers. It felt like a fog-of-war map—I had to explore, unlock nodes, and build routes.

After countless small tests, I built a working, cost-effective flow tailored to myself. I avoided high-fee routes, optimized timing, and even exploited currency fluctuations for marginal gains.

Some goals seemed impossible at first—like sending funds to countries with little infrastructure. But I eventually figured out how: crypto deposits, direct virtual currency payments, fiat-to-stablecoin automation, specialized remittance apps bypassing banks… I made the impossible possible.

This transition—from “unreachable” to “path unlocked”—felt exactly like rebuilding a network architecture.

I wasn’t just transferring money. I was redefining the structure of value transmission.

Sounds complex? It’s really just a classic systems design problem:

• How do systems communicate and transfer data?
• How do we handle format (currency) conversions?
• Which nodes are reliable? Which paths are low-latency and low-failure?
• How do we move a “data packet” (money) through protocols (remittance channels) to the destination?
• Can it feel seamless from the user’s (my) perspective?

That’s architecture: not feature-building, but designing a coherent, maintainable, scalable system.

Each card is a node; each interface is a protocol. Every iteration? A tiny architectural optimization.

It’s route planning + interface negotiation + user experience. Sounds familiar, architect?

Card enthusiasts aren’t just saving money. They’re reconstructing the world’s financial logic and taking control.

5. Architectural Literacy Forged Through Card Craft

Through every route choice, failed experiment, cost balancing act, and risk-management adjustment, card enthusiasts are honing a kind of architectural mindset. No servers, no code—but plenty of real-world structure tuning and efficiency refinement. That process? It’s hands-on system design.

All these behaviors, over time, naturally evolve into core architectural instincts:

In many ways, card enthusiasts are simulating what it means to think like a systems architect—using the real world as their playground.

6. My Reflection

Fees are the enemy. Channels are sacred. Paths are art.

I didn’t become a card enthusiast because I love swiping cards—I became one because through each experiment, I found beauty in structure. We may not write code or run servers, but every money transfer, every optimized flow—it’s all a personal exercise in system design.

From prepping for the architecture certification to building my daily financial routes, I’ve come to realize:

What I enjoy isn’t just getting things done—it’s making the path elegant.

What others see as petty tricks, I see as system aesthetics.
What others call loophole hunters, I call life architects.

Cardcraft isn’t just about saving money—it’s a real-world sandbox to train your sense of system design: visualizing problems, iterating solutions, aligning logic with beauty.

It’s not a waste of time. It’s a tactile, tangible, deeply personal “practice space” for designing real-world systems.

It’s not about saving money. It’s about skill-building.
It’s not about invention. It’s about choosing the right structure.
Whether it’s designing systems or optimizing card flows, the point isn’t how much you saved or how many lines you wrote—it’s how much better you understand how the world works.

And I? I’m the kind of person who stands in front of an ATM for 10 minutes—just to calculate the optimal fee path. Maybe I don’t have a server to deploy, but I’m still architecting.

Conclusion: Life Is the Ultimate Architecture

Every time we swipe a card, transfer money, evaluate a route, or make a combination decision—we’re engaging in an invisible act of system design.

Architecture isn’t just about servers and APIs. Sometimes, it’s hidden between wallets, bank cards, and payment methods.

At the end of the card optimization path, perhaps what we find is not a loophole hunter—

—but a life architect in disguise.

Appendix: My Capital Flow in Code

This code isn’t meant to be executable—it’s a model of how I think about my real-world money flows. It’s how I express everyday logistics through architectural language.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

// My cross-border capital flow (illustrative)

func RouteCNYtoJPY(CNY float64) JPY float64 {
    HKD := BOCExchange(CNY, to="HKD")
    log.Printf("Exchanged %.2f CNY to %.2f HKD", CNY, HKD)

    Transfer(HKD, from="BOC", to="BOCHK", by="pbservice")
    log.Println("Transferred via pbservice → BOCHK")

    Transfer(HKD, from="BOCHK", to="Wise", by="fpservice")
    log.Println("Transferred via fps → Wise")

    JPY := WiseConvert(HKD, to="JPY")
    log.Printf("Converted %.2f HKD to %.2f JPY via Wise", HKD, JPY)

    Deposit(JPY, to="Revolut", with="ApplePay")
    return JPY
}

A code snippet built not for execution, but for expression—a symbolic blueprint connecting everyday money logic to architectural thinking.

Disclaimer: This article is for entertainment and personal documentation purposes only. It is not intended as financial or legal advice. Please enjoy responsibly.