DEV Community: Zhonglian Network

Designing Software That Runs for Ten Years: Architecture Lessons from 14 Years in Production

Zhonglian Network — Tue, 29 Sep 2026 06:46:08 +0000

By Zhonglian Network — custom software development, Nanning, China

Most architecture writing is about greenfield systems. That's the easy part. The hard question is: what makes a system still running, unchanged in its core, after a decade?

We have three systems that have crossed or are crossing that line:

A school cafeteria procurement platform serving 140+ schools — in production for over 10 years, never rewritten.
A POS payment system built on the UnionPay 8583 protocol — still the core payment architecture for multiple commercial deployments.
An education platform serving 100+ institutions and 1M+ end users, holding roughly 15 TB of data.

None of these are clever. That's the point. Here's what actually mattered.

1. The database schema is the real API

Application code gets rewritten every few years. The schema doesn't. Every long-lived system we have owes its survival to schema decisions made in week one.

What worked:

Explicit columns over EAV. Early on, someone always proposes an entity-attribute-value table "so we can add fields without migrations." We've seen this fail every time. A procurement system needs purchase_order.amount to be a DECIMAL(18,2) with a constraint — not a row in an attributes table. Query performance and data integrity both collapse under EAV.
Never delete. Add a status. Financial records get soft-deleted with an audit trail. The school procurement system can reconstruct every state a purchase order passed through, ten years back. That's not a feature we built later — it was designed in.
Surrogate keys everywhere. Natural keys (school code, student number) change. We learned this the expensive way: a primary key that changes is a primary key you'll regret.
Money as integer minor units or DECIMAL, never FLOAT. Obvious, and still violated constantly.

What we'd do differently: we normalized aggressively in 2012. Some of those joins are now the slowest part of the system. A few denormalized read columns for reporting would have paid for themselves many times over.

2. Financial systems need idempotency at the protocol layer

The UnionPay 8583 POS system is the clearest example of a decision that has aged well.

8583 is a byte-oriented financial messaging protocol — fixed-format bitmaps and fields, sent over TCP. The critical property is that the network is not reliable, but the transaction must be exactly-once.

Our design, simplified:

POS terminal                Our gateway                UnionPay
     |                          |                         |
     |-- 0200 (sale req) ------>|                         |
     |                          |-- 0200 ---------------->|
     |                          |<-- 0210 (response) -----|
     |<-- 0210 (response) ------|                         |
     |                          |                         |
   [timeout / no response]      |                         |
     |-- 0200 (retry) --------->|                         |
     |                     [dedup by STAN + RRN]          |

Three rules that made this work:

Every request carries a unique trace number (STAN) plus a retrieval reference number (RRN). The gateway keeps a dedup table keyed on those. A retry with the same key returns the original result — it does not execute a second charge.
The gateway, not the terminal, is the source of truth. Terminals cache but never decide. If a terminal is destroyed, no money is lost.
Reconciliation runs daily and is non-optional. A batch job compares our ledger against UnionPay's settlement file. Any mismatch is an incident, not a warning. In ten years, this has caught issues that would otherwise have become customer-visible.

The generalizable lesson: for anything involving money, design the retry path before the happy path. Ask "what happens if this message arrives twice?" for every write endpoint. If the answer requires human intervention, the design is wrong.

3. Multi-tenancy: separate the data, share the schema

The 140-school procurement platform is multi-tenant. We chose a shared schema with a tenant_id column — not separate databases per school.

The trade-off:

Approach	Pros	Cons
Shared schema + tenant_id	One migration path, cheap ops, easy cross-tenant reporting	Risk of tenant data leakage if a query forgets the filter
DB per tenant	Strong isolation, per-tenant backup/restore	140 migrations per release; ops cost scales linearly

We chose shared schema. To make it safe, we enforced tenant filtering at the data-access layer, not in hand-written SQL — every query goes through a repository that injects the tenant predicate. Hand-written SQL is where isolation bugs live.

If we were doing it today with stricter compliance requirements, we'd likely use row-level security in the database itself rather than trusting the application layer.

4. Scaling to 1M users and 15 TB: boring beats clever

The education platform taught us that scale problems are usually access-pattern problems, not capacity problems.

What actually mattered:

Pagination discipline. Never SELECT * without a bounded range. The first version of our admin console loaded a full institution list; that page became unusable around 200k rows. Keyset pagination fixed it permanently.
Move files out of the database early. Binary blobs in the DB made backups grow linearly with usage. Object storage plus a reference table changed our backup window from hours to minutes.
Read replicas for reporting. Reports were competing with transactional traffic for the same locks. Isolating them was a one-week change that removed an entire class of incidents.
Partition the biggest tables by time. The 15 TB is dominated by a handful of append-only tables. Time-based partitioning made archival and retention possible.

None of this is novel. It's just that teams skip it until it hurts.

5. What we'd tell a team starting today

Five rules, ordered by how much pain they prevent:

Write the schema as if you'll still be querying it in 2036. Because you will.
Design the idempotency key before the endpoint. Especially for payments, orders, and anything that sends a message.
Enforce invariants in the database, not only in the service layer. Application code has bugs; constraints don't.
Keep an audit trail from day one. Retrofitting one is a project; designing one is a column.
Prefer the boring technology. The systems that survive are the ones whose dependencies still exist. We still run .NET and Oracle/MySQL systems from 2012 without drama.

A note on what this means for offshoring

If you're evaluating an offshore partner, the question that separates vendors isn't "what's your stack?" — it's "show me something you built that's still running."

Anyone can ship an MVP. Ask for the system that's been in production for eight years, and ask what they'd change. A team that has maintained long-lived systems will answer that question with specifics, not adjectives.

About Zhonglian Network

Software development company based in Nanning, China, operating since 2012.

Custom software development — web, mobile, desktop
Smart ticketing and access-control systems
POS / membership / payment systems (UnionPay 8583 protocol)
AI application development and enterprise system integration

Stack: .NET Core / C#, Python, Go, Java, Oracle, MySQL, Redis, Vue, React, Flutter, Taro
Track record: 100+ institutions and 1M+ end users on one platform; a procurement system in production 10+ years; ticketing systems deployed commercially across multiple provinces. 5 national invention patents.

Contact: xiaoru@zl771.cn

Tags: software architecture, legacy systems, payment systems, UnionPay 8583, offshore development

Custom Software Development: China vs Eastern Europe — An Honest 2026 Cost Comparison

Zhonglian Network — Tue, 29 Sep 2026 06:12:10 +0000

By Zhonglian Network — custom software development, Nanning, China

If you're a CTO or founder building a shortlist of offshore development partners in 2026, you've almost certainly been quoted Eastern Europe first. Poland, Romania, and Ukraine have dominated Western offshoring for a decade, and for good reason: time-zone overlap, cultural proximity, and a mature outsourcing industry.

China rarely makes the list. That's a gap worth examining — not because China is cheaper (it usually isn't, at the top end), but because the shape of what you get is different.

This is a cost and capability comparison written from the inside. We're a Chinese software company, so treat our bias as disclosed. We'll also tell you where Eastern Europe wins, because pretending otherwise wouldn't help you make a decision.

1. The rate card (mid-level full-stack, monthly, 2026)

Region	Monthly blended rate	Typical engagement model
US / Western Europe (direct hire)	$9,000 – $15,000	FTE + benefits
Eastern Europe (Poland, Romania, Czechia)	$4,500 – $7,500	Dedicated team / staff augmentation
Eastern Europe (Ukraine, Belarus-adjacent, Serbia)	$3,000 – $5,500	Fixed-scope or dedicated team
India	$2,000 – $4,000	Wide quality variance
China (tier-2 city, e.g. Nanning, Chengdu, Xi'an)	$2,500 – $5,000	Dedicated team / fixed-scope
China (Beijing / Shenzhen / Shanghai)	$4,000 – $7,000	Approaches Eastern Europe

The honest read: at the senior end, China and Eastern Europe are converging. China's tier-1 cities are no longer cheap. The cost advantage — where it exists — lives in tier-2 cities and in system complexity, not in hourly rates.

If your decision is purely "lowest rate per developer," India still wins. If your decision is "lowest total cost of a system that survives five years," the calculation changes.

2. Where the real cost difference hides

Hourly rate is the least interesting number in an offshore deal. Three others matter more.

2.1 Rework cost

A developer at $30/hr who requires 40% rework costs you more than a developer at $50/hr who doesn't. This is where "cheap" offshoring quietly becomes expensive.

Our observation after 14 years: the failure mode is almost never coding skill. It's requirements drift — nobody wrote down what "done" meant, so every sprint ends in a negotiation.

2.2 Communication overhead

A time zone with zero overlap means every clarification costs a day. If your team asks 6 clarifying questions a week, that's 6 days of latency per week.

Eastern Europe (UTC+1/+2): 4–6 hours of live overlap with Western Europe, 2–3 with US East Coast.
China (UTC+8): full overlap with APAC; 3–4 hours with Europe (their morning, our afternoon); zero with US.

This is China's single biggest practical disadvantage for US clients. Be honest about whether your team can work async.

2.3 Turnover

If the 3 developers you met are replaced in month 4, you've paid onboarding cost twice and lost all context.

Ask for named engineers in the contract, and ask what their tenure is. Vendors that can't answer that are selling you a bench, not a team.

3. Where China genuinely wins

3.1 Hardware + software integration

If your product touches a physical device — POS terminals, access-control gates, IoT sensors, ticketing turnstiles, vending hardware — China is hard to beat. The supply chain is local, so engineers prototype against real devices instead of an emulator and a hope.

We built a POS payment system on the UnionPay 8583 protocol that still serves as the core architecture for multiple commercial deployments. That work requires engineers who understand both a banking protocol and the physical terminal it runs on. In Eastern Europe you can find the protocol expertise; the hardware ecosystem is a flight away.

3.2 Systems built to run for a decade

Chinese software teams are culturally used to building systems that survive heavy load for years without a rewrite. One system we built — school cafeteria procurement across 140+ schools — has run for over 10 years in production.

That's a different engineering culture from "ship an MVP and iterate in public." Neither is wrong. They fit different problems.

3.3 Cost at scale, not at prototype

For a 2-week prototype, Eastern Europe is often the better call — faster kickoff, easier calls. For a 12-month system with 5+ engineers, the tier-2 China rate difference compounds into six figures.

3.4 AI + application integration

China's AI tooling ecosystem (LLM APIs, model serving, domestic cloud) is deep and cheap. If your product needs AI features built into an existing enterprise system, the local toolchain is mature.

4. Where Eastern Europe wins

Time-zone overlap with the US — decisive if your team works synchronously.
Cultural and legal proximity to the EU — GDPR familiarity, EU contract norms, easier due diligence.
English fluency at the team level — generally higher baseline than Chinese teams.
Easier reference checks — you likely know someone who has hired there.
Lower geopolitical friction for regulated industries.

If you're a US company needing daily standups with your dev team, hire in Eastern Europe or Latin America. This isn't a knock on China; it's arithmetic.

5. A decision framework

Your situation	Better fit
US-based, needs synchronous daily collaboration	Eastern Europe / LatAm
EU-based, standard web SaaS, mid-complexity	Eastern Europe (safest default)
Product touches hardware (POS / IoT / access control)	China
Long-lived enterprise system, 12+ months, cost-sensitive	China (tier-2 city)
APAC / Australia / SEA customers	China
Lowest absolute rate, quality risk acceptable	India
AI features inside an existing enterprise system	China

6. How to vet any offshore team (China or Eastern Europe)

Demand a named team roster — with tenure. Put it in the contract.
Interview the actual engineers in English — an architecture discussion, not a language test. You'll know in 20 minutes.
Run a small paid pilot (2–4 weeks) before a long engagement.
Nail down IP in writing: you own all source code, it lives in your repository, and data exports in an open format at any time.
Ask the exit question: "What happens when we want to leave?" Good vendors answer instantly. Bad ones get vague.
Ask what broke last time and how they fixed it. Anyone who claims nothing ever breaks is selling.

About Zhonglian Network

We're a software development company based in Nanning, China, operating since 2012.

What we do

Custom software development — web, mobile, desktop
Smart ticketing and access-control systems (scenic areas, water parks, museums, exhibitions)
POS / membership / payment systems (UnionPay 8583 protocol)
AI application development and enterprise system integration

Stack: .NET Core / C#, Python, Go, Java, Oracle, MySQL, Redis, Vue, React, Flutter, Taro

Track record: a platform serving 100+ institutions and 1M+ end users; a procurement system running 10+ years in production; ticketing systems deployed commercially across multiple provinces. We hold 5 national invention patents.

If you're evaluating offshore partners, we're happy to have a technical conversation — no sales pitch.

Contact: xiaoru@zl771.cn

Tags: offshore development, software outsourcing, China vs Eastern Europe, custom software development, cost comparison

How to Hire a Reliable Software Development Team in China (2026 Guide)

Zhonglian Network — Mon, 28 Sep 2026 15:14:17 +0000

If you're a CTO or founder looking to offshore software development, China probably isn't the first country on your shortlist. India, Poland, and Ukraine dominate that conversation.

After 14 years of building software — including a platform serving 100+ institutions and 1M+ end users — I think that's a mistake. Here's an honest breakdown.

The real cost picture (2026)

Monthly cost for a mid-level full-stack developer:

Region	Monthly cost
US / Western Europe	$8,000 – $14,000
Eastern Europe	$3,500 – $6,000
India	$2,000 – $4,000
China (tier-2 city)	$2,500 – $4,500

The interesting part isn't the rate — it's what you get for it.

What China actually does better

1. Hardware + software integration

If your product touches hardware (POS terminals, access control, IoT sensors), China is hard to beat. The supply chain is local, so engineers prototype against real devices instead of emulating them.

We built a POS payment system on the UnionPay 8583 protocol that still runs as core architecture for multiple commercial deployments.

2. Complex, long-lived systems

Chinese teams are used to building systems that run for a decade under heavy load. One system we built for school procurement across 140+ schools has been running 10+ years without a rewrite.

3. Time zone overlap with Asia, workable with Europe

China (UTC+8) overlaps fully with Southeast Asia and Australia, partially with Europe, and not at all with the US. If you're in the US, expect async work with a 1-2 hour daily overlap.

The three things that actually go wrong

Problem 1: You hire a body shop, not a team

"We have 50 developers" often means 50 contractors on benches. Ask who specifically will work on your project, and require their names in the contract.

Problem 2: Communication is worse than advertised

"Fluent English" on a résumé and "can run a design review in English" are different skills. Do the technical interview in English — an actual architecture discussion. You'll know within 20 minutes.

Problem 3: IP and source code ownership gets murky

Some vendors retain source code ownership and license it to you. The contract must state:

You own all source code and IP
Code is delivered to your own repository
Data can be exported in an open format at any time

A practical vetting process

Ask for a specific team roster — names, roles, tenure
Do the technical interview in English with actual engineers
Request a small paid pilot (2-4 weeks) before a long contract
Verify source code ownership in writing
Ask what happens when you want to leave — this separates good vendors from bad ones fast

About us

Zhonglian Network is a software development company in Nanning, China, operating since 2012. We build custom software, smart ticketing systems, POS/membership platforms, and AI applications.

Stack: .NET Core / C#, Python, Go, Java, Vue, React, Flutter. We hold 5 national invention patents.

Happy to have a technical conversation — no sales pitch.

Contact: xiaoru@zl771.cn