DigitalOcean Managed PostgreSQL: Minimal HA Design for a Private‑Networking Microservice

Problem

A stateless microservice needs a durable, highly available PostgreSQL database that is invisible to the public internet, automatically recovers from node failures, and retains daily backups for recovery. The service runs in a single DigitalOcean region, so the solution must rely on the managed offering’s built‑in HA and backup features without adding extra replication layers.

Requirements

• Private‑networked database cluster with no public IP.
• Automatic failover to two read replicas within seconds.
• Daily backups retained for 35 days.
• Encrypted data at rest (AES‑256) and in transit (TLS).
• Simple operational checks: status, replication lag, backup existence.
• Minimal cost: use the smallest cluster that satisfies the above.

Minimal Suitable Design

The DigitalOcean Managed PostgreSQL service automatically provisions a primary node and two replicas. The smallest plan that offers this topology is the “Standard” tier with a 1‑CPU, 2‑GB instance, but the design is identical for larger tiers.

Architecture diagram (textual):

+----------------+   Private VPC   +----------------+   Private VPC   +----------------+
|  Primary Node  | <------------> |  Replica 1     | <------------> |  Replica 2     |
+----------------+                 +----------------+                 +----------------+
          |                                 |                                 |
          |                                 |                                 |
          +---------------------------------+---------------------------------+
                                 |  Microservice App (private IP)

All nodes share the same VPC subnet. The microservice connects via the cluster’s private endpoint, ensuring zero exposure to the public internet.

Trust/Data Boundaries

• Network isolation: Enable private_networking and disable public_connection. Only VPC CIDR blocks can reach the cluster.
• Encryption: DigitalOcean enforces AES‑256 at rest and TLS 1.2+ for all connections by default.
• Access control: Use database roles with least privilege. The microservice role should have CONNECT and necessary DML rights only.
• Monitoring boundary: Expose only the cluster’s health metrics to DigitalOcean Monitoring; do not publish internal metrics externally.

Operational Checks

All checks can be performed via the DigitalOcean API or the doctl CLI. Replace {id} with the cluster ID.

1. Cluster status – ensure the cluster is online.

   curl -s -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
     https://api.digitalocean.com/v2/databases/{id}
     | jq '.database.status'
   # Expected output: "online"
   

2. Replication count – verify two replicas.

   curl -s -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
     https://api.digitalocean.com/v2/databases/{id}
     | jq '.database.replica_count'
   # Expected output: 2
   

3. Private networking flag – confirm no public endpoint.

   curl -s -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
     https://api.digitalocean.com/v2/databases/{id}
     | jq '.database.settings.private_networking'
   # Expected output: true
   

4. Daily backups – list recent backups.

   curl -s -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
     https://api.digitalocean.com/v2/databases/{id}/backups
     | jq '.backups[].created_at'
   # Verify at least one backup per day.
   

5. Replication lag – run on the primary.

   psql "host={primary_private_ip} port=5432 user={user} dbname={db}" -c "\set interval 1\s\
   SELECT client_addr, state, sync_priority, sync_state, write_lag, flush_lag, replay_lag FROM pg_stat_replication;"
   # All lag values should be < 1s for healthy replication.
   

Failure Modes & Design Changes

DigitalOcean’s Managed PostgreSQL handles primary node failure automatically. However, certain conditions warrant design adjustments:

• Region loss: If the region becomes unavailable, the entire cluster and backups vanish. Mitigation: Deploy a second cluster in a different region and use logical replication or a third‑party tool to sync data.
• Backup retention policy change: If you need longer retention, consider exporting WAL archives to an external bucket or using a separate backup strategy.
• High traffic spikes: The default 1‑CPU node may become a bottleneck. Scale up the instance size or add read replicas in a separate cluster for read scaling.
• Security breach: If you discover unauthorized access, rotate all database credentials immediately and review VPC firewall rules.

To change the design, you can alter the cluster via the API or doctl databases update, but note that adding or removing replicas is not supported; you must recreate the cluster with the desired topology.

Concrete Example: Creating the Cluster

Use doctl to spin up the minimal HA cluster:

doctl databases create myapp-db \
  --engine=pg \
  --region=nyc3 \
  --size=db-s-1vcpu-2gb \
  --private-networking \
  --no-public-connection \
  --replica-count=2

After creation, retrieve the private connection string:

doctl databases list --format ID,Name,PrivateConnectionString
# Example output: myapp-db: postgresql://user:pass@10.0.0.5:5432/mydb

Configure your microservice to use this connection string. Store credentials in a secrets manager or Kubernetes secret, never in code.

Conclusion

By leveraging DigitalOcean Managed PostgreSQL’s built‑in replication, private networking, and automated backups, a microservice can achieve high availability with minimal operational overhead. The architecture outlined above satisfies strict isolation, rapid failover, and daily backup retention while keeping costs low. Regular status checks and monitoring of replication lag ensure that the cluster remains healthy, and awareness of the single‑region limitation allows teams to plan for geographic resilience if needed.