Mirror architecture: keeping a Vietnam copy while your primary stays offshore

You run your primary application stack in Singapore, Frankfurt, or Oregon. It has been running fine for years. Then your legal team forwards Decree 53, a Vietnamese regulation that requires a copy of certain personal data to be stored inside Vietnam. The decree does not ban copies abroad. It does not force your entire infrastructure to move. It demands a local copy, and that is a different engineering problem.
越南法规要求境内存储数据副本,但允许主站保留在海外。
Vietnam’s regulation requires a data copy inside the country but allows your primary site to remain offshore.
This article covers the only pattern that works at scale: an asynchronous replica inside a Vietnam datacenter. No live-transaction routing. No load balancer reshuffle. A vietnam data mirror server that receives a read-only copy of your data and stands ready for compliance checks, disaster recovery, or read-offloading for users inside Vietnam.
What Decree 53 Actually Requires of Storage
Decree 53/2022/ND-CP and its successor amendments do not replicate GDPR's full data residency framework. They target specific categories, user profile data, transaction history, and log data of users who are Vietnamese citizens, and mandate that this data be stored on servers physically located within Vietnam. The regulation explicitly permits the same data to be stored outside Vietnam as long as a domestic copy exists.
This is critical to understand: you do not need to migrate your primary infrastructure. You need a domestic mirror. The Vietnamese data protection authority (A05 under the Ministry of Public Security) expects the capability to access that data on request. They do not require that the copy be live-editable, a read-optimised replica that lags by minutes is acceptable for compliance, provided it can be queried on demand.
Three major datacenter operators serve this role in Vietnam: Viettel IDC (the military-run telecom, largest inland network), VNPT IDC (the state postal/telecom group), and FPT Telecom (the private-sector alternative). All three operate Tier 3 facilities and peer domestically, which means traffic between a Vietnam VPS and Vietnamese users stays inside the country at roughly 100 Mbps.
Replication Patterns That Work Across the Border
The distance from Vietnam to any major global hub adds at least 40-60 ms of round-trip time (RTT), Hanoi to Singapore is about 45 ms, to Tokyo around 70 ms, to London or the US West Coast over 180 ms. Synchronous replication (where every write must commit on both ends before the application gets a success) is not viable at these latencies. Your writes would stall, your users would time out, and your database connection pool would fill with waiting transactions.
The only practical model is asynchronous replication. The primary stays offshore and commits locally. A change stream, MySQL binlog, PostgreSQL WAL, or Kafka topic, ships to the Vietnam replica. The replica applies events as they arrive, lagging by seconds to minutes depending on network health.
| Replication Method | Typical Lag (Hanoi) | Risk Profile | Best For |
|---|---|---|---|
| MySQL group replication (async) | 1-8 seconds | Lag spikes during international congestion | MySQL/MariaDB workloads |
| PostgreSQL streaming replication (async) | 0.5-5 seconds | Replication slot stalls if Vietnam VPS lags | PostgreSQL, GIS data |
| Debezium → Kafka → sink connector | 2-15 seconds | Kafka broker failure breaks the stream | Polyglot stacks (MySQL + MongoDB + Elasticsearch) |
| File-based rsync (periodic) | 15-60 minutes | No crash consistency if source changes mid-copy | Static datasets, logs, backup archives |
For most production databases, MySQL binlog replication or PostgreSQL streaming replication is the default choice. They are well-documented, require no middleware, and recover automatically after transient network failures, provided you configure sync_binlog and innodb_flush_log_at_trx_commit correctly on the primary (set both to 1 for durability during lag).
Bandwidth Constraints, What 100 Mbps Domestic Means
A common mistake is assuming a Vietnam VPS has the same international bandwidth as a US or European instance. It does not. The domestic link between the Vietnam VPS and local users runs at 100 Mbps on a 1 Gbps port, that is 100 Mbps throughput inside Vietnam, not 1 Gbps. The international pool shared across the datacenter is roughly 4 to 10 Mbps per customer depending on current load. This is not a fault of any particular provider; it is the reality of trans-Pacific cable capacity and peering costs.
For a vietnam data mirror server, this means:
- The cross-border replication stream (source → Hong Kong/Singapore → Vietnam) competes with every other cross-border service on the same international pool. Plan for 2-5 Mbps sustained transfer for your WAL or binlog stream, not 100 Mbps.
- If your primary generates 10 Mbps of continuous changes (common for a medium-traffic e-commerce site), the replication stream can saturate the international pool and cause packet loss. You must throttle the sender, MySQL's
MASTER_DELAYor PostgreSQL'smax_wal_senderswith a rate limit. - One replication stream per database. Do not attempt to replicate 15 databases simultaneously over the same 4-10 Mbps pipe unless you accept minutes of lag.
- If you need bulk initial sync (the first time you set up the replica), the 4-10 Mbps ceiling means a 100 GB database takes 24-48 hours. Plan maintenance windows accordingly. Compress the dump with
zstd, it is typically 3-5x faster than gzip and reduces transfer time.
The domestic side is better: once the data is inside Vietnam, the Vietnam VPS can serve local users at 100 Mbps. That is sufficient for most read-heavy applications, API reads, asset delivery, check queries from the ministry. If you need more, a rent a VPS in Vietnam with dedicated resources can be paired with a CDN that caches static content at domestic edge nodes (Viettel's own CDN or Cloudflare's Vietnam POP).
Cost Model, What a Vietnam Replica Actually Costs
An offshore primary runs in a familiar pricing zone, DigitalOcean droplets at $12-48/mo, Hetzner at €5-30/mo. The Vietnam replica adds a second line item. The base VPS needed for a mirror is not large: the replica only needs CPU and RAM to apply the replication stream and serve occasional compliance queries. Storage is the real factor because the replica holds a full copy of the dataset.
A workable vietnam data mirror server spec starts at 2 GB RAM / 2 vCPU / 40 GB NVMe, enough for a small-to-medium MariaDB or PostgreSQL replica handling a few hundred writes per second. Monthly cost for such a configuration on Vietnamese infrastructure, including a dedicated IPv4 from the Vietnam range, full root access, and NVMe storage, typically runs between $8 and $16. Snapshots and backups are provided by the operator; factor one extra snapshot per week at the storage rate.
Compare that to the cost of maintaining a second full production stack in Vietnam, load balancers, application servers, database clusters, cross-connect circuits, and the mirror approach is dramatically cheaper. You are not running a live application layer in Vietnam. You are running a single read-optimized database server.
| Component | Offshore Primary | Vietnam Replica |
|---|---|---|
| VPS (2 vCPU / 4 GB / 80 GB NVMe) | $12-24 | $14-20 |
| Dedicated IPv4 | Included or $1-2 | Included |
| Bandwidth (domestic) | N/A | 100 Mbps (no cap) |
| International bandwidth | 1-10 Gbps | 4-10 Mbps (shared pool) |
| Snapshots + backups | $2-5 | Usually included or $1-2 |
| Total monthly | $14-31 | $15-22 |
The Vietnam tier is generally not cheaper than a comparable Hetzner or DigitalOcean VPS, the hardware cost and bandwidth economics are different. What you pay for is the local IPv4 and domestic peering: the data sits on a server that is physically inside Vietnam, on a network that peers directly with Viettel, VNPT, and FPT. No submarine cable needed to reach it from inside the country.
Immediate Actions to Build the Mirror
If you are starting from scratch, here is the minimal sequence:
- Order a Vietnam VPS with at least the specs above. Choose an OS you already run on the primary, Ubuntu 24.04 LTS or Debian 12 are the safest picks. Install the same database version as your primary (MariaDB 11.x, PostgreSQL 16, or MySQL 8.0).
- Configure the replica database exactly as the primary, but with replication role enabled (
server-idin MySQL,hot_standby = onin PostgreSQL). Disable the application schema if you only need a copy, no WordPress tables unless you plan to serve reads from it. - Open the replication port on the Vietnam VPS firewall (3306 for MySQL/MariaDB, 5432 for PostgreSQL) and restrict access to only the primary server's IP. Use
ufwornftables, do not leave it open. - Initial sync: take a consistent dump from the primary (
mysqldump --single-transaction --master-dataorpg_dump -Fc), compress it withzstd, transfer it to the Vietnam VPS over SSH, and restore. Expect this to take time. - Start the replication stream: establish the binlog position or LSN and enable the replica. Verify with
SHOW SLAVE STATUS\GorSELECT * FROM pg_stat_replication, look forSeconds_Behind_Masterunder 10. - Monitor replication lag with a simple cron script or Prometheus exporter. If lag exceeds 60 seconds, alert. The most common failure is a transient network hiccup that stalls the replication thread, set
slave_net_timeout(MySQL) orwal_receiver_timeout(PostgreSQL) to 30-60 seconds so it retries automatically instead of waiting forever.
What the Mirror Cannot Do
An asynchronous replica in Vietnam is not a live-active-active setup. If you promote the replica to be the new primary (in a disaster scenario where your offshore stack goes down), you will lose any transactions that had not yet reached it, the lag. The data is between seconds and minutes behind at any given moment. This is acceptable for compliance (the regulation asks for access to data that exists, not data that is instantly fresh) and for read-offloading, but not for failover under strict RPO limits.
If you need sub-second RPO (zero data loss at failover), you must run synchronous replication, which requires sub-5 ms RTT between sites. Vietnam to anywhere accessible is 40+ ms. The only zero-loss option inside Vietnam is a two-datacenter setup within the country, Viettel IDC Hanoi + VNPT IDC HCMC, for example, both hosting replicas of your primary. That adds complexity and cost. For most foreign companies complying with Decree 53, async minutes-of-lag is the correct engineering trade-off.
中文摘要
越南第53号法令要求将特定用户数据存放在越南境内的服务器上,但允许主站保留在海外。最实用的方案是在越南数据中心部署一个异步复制副本(MySQL binlog 或 PostgreSQL streaming),副本通常滞后几秒到几分钟,可以满足合规检查和越南本地读请求。越南国内带宽为100 Mbps,国际共享带宽仅约4-10 Mbps,因此复制流必须限速。硬件方面,2 vCPU / 4 GB RAM / 80 GB NVMe 的越南 VPS 月费约15-22美元,加上海外主机的费用,总成本可控。本文提供技术概述,不构成法律意见,建议咨询越南律师。
FAQ
Does Decree 53 require me to store all data in Vietnam, or only a copy?
Only a copy of the categories listed in the decree, user profile data, transaction history, and logs of Vietnamese citizens, must be stored domestically. The primary dataset can remain outside Vietnam. The copy must be accessible on demand from within Vietnam.
What replication lag is acceptable for compliance?
The regulation does not specify a maximum lag. In practice, the Ministry of Public Security (A05) expects the data to be queryable within a reasonable timeframe. Minutes of lag is generally acceptable for compliance checks, but you should be able to show that the replica updates continuously, not a static snapshot from a week ago.
Can I run the Vietnam replica on a low-cost tier with 1 GB RAM?
For a small dataset (under 10 GB) and low write volume, 1 GB RAM may work, but the database caches heavily for replication apply performance. 2 GB is the safe minimum for MariaDB or PostgreSQL. Below that, the operating system may swap during peak replication, causing lag buildup.
How do I monitor replication lag effectively?
Use MySQL's SHOW SLAVE STATUS (the Seconds_Behind_Master field) or PostgreSQL's pg_stat_replication view. Set up a Prometheus node_exporter with a replication lag metric and alert when lag exceeds 30 seconds Combined with a simple health check script that restarts the replication thread on failure (STOP SLAVE; START SLAVE; in MySQL), you cover 90% of common failure modes.
Should I use the Vietnam VPS for live read traffic too?
Yes, if your application can tolerate stale reads (the replica is behind by seconds). Read-offloading from the replica reduces load on the offshore primary and gives Vietnamese users a domestic endpoint, traffic stays inside Vietnam at 100 Mbps instead of crossing the submarine cable. This is the single biggest performance win from the mirror.
Is there a risk the replica gets out of sync permanently?
If the replication thread stalls for an extended period (hours), the primary may purge its binlogs before the replica catches up. Set expire_logs_days (MySQL) or wal_keep_size (PostgreSQL) high enough, 7 days is safe, and monitor the lag. If the replica is unreachable for more than 48 hours, a fresh sync is safer than trying to patch a gap.
Disclaimer: This article provides general technical information about data replication architecture. It does not constitute legal advice. Decree 53 and related Vietnamese regulations are subject to interpretation by the competent authorities. You should consult a Vietnamese-qualified lawyer to ensure your compliance approach meets the current regulatory requirements.
Related articles
- What happens after A05 issues a written storage request, the inspection process for a Decree 53 data order on your Vietnam replica
- Does Decree 53 require my company to host data in Vietnam, a plain-language breakdown of the regulation for foreign operators
- How to rent a VPS in Vietnam as a foreign company without a local entity
- Should your CDN origin sit inside Vietnam, latency caveats
越南数据镜像架构与合规副本
法令要求数据存储在越南,并没有禁止在境外保留副本。镜像架构的关键在于复制方式、同步延迟和成本控制。主库在境外、越南保留一份可查询的副本,是目前最稳妥的做法。


