Database reconnect retry pattern
Automatic reconnection with exponential backoff and circuit breaker.
Database connections drop — the server restarts, network hiccups, a firewall rule changes. Most applications should not fail immediately; instead, they should reconnect automatically with exponential backoff so transient outages are invisible to users.
This template maps the complete reconnect strategy: detect the failure, attempt reconnection with exponential backoff, and open a circuit breaker to stop retrying when the database is genuinely down. Teams use this pattern to build resilient backends where brief database restarts don't cascade into user-visible downtime.
When to use this template
- Connection pool design — decide how many retry attempts to allow, what backoff to use, and when to open the circuit breaker.
- Incident recovery — when a database outage happens, trace which backoff parameters helped or hindered recovery time.
- Production readiness checklist — add this diagram to your runbook so on-call engineers understand your reconnect strategy.
How to adapt it
Add your specific database and failure modes:
- Set retry count and backoff timing to match your SLA (faster backoff for high-availability systems, slower for cost-conscious ones).
- Add a replica failover branch if you run read replicas; redirect reads while retrying the primary.
- Insert a bulkhead pattern to isolate database failures from other services (if DB is down, shed load on timeout tasks but keep APIs responsive).
Visual edits regenerate clean code, so you can adjust retry strategy and backoff timing in the editor without touching Mermaid syntax directly.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
flowchart TD
A[Query execution] --> B{Connection active?}
B -->|Yes| C[Execute on pool]
C --> D{Query succeeded?}
D -->|Yes| E[Return result]
B -->|No| F{Is circuit open?}
F -->|Yes| G[Fail fast & alert]
F -->|No| H{Retry count < 5?}
H -->|Yes| I[Close existing connection]
I --> J[Wait with backoff]
J --> K[Attempt reconnect]
K --> L{Reconnect succeeded?}
L -->|Yes| M[Reset retry counter]
M --> C
L -->|No| N[Increment retry count]
N --> O{Backoff >= 30s?}
O -->|Yes| P[Open circuit breaker]
P --> G
O -->|No| H
D -->|No| Q{Retryable error?}
Q -->|Yes| R[Retry query]
R --> C
Q -->|No| S[Return error]
Frequently asked questions
- What is a database reconnect retry pattern?
- It's the strategy your application uses when it loses connection to the database. Instead of failing immediately, it waits and tries to reconnect. Exponential backoff means you wait 1 second, then 2 seconds, then 4 seconds, so you don't overwhelm a recovering database. A circuit breaker prevents infinite retries when the database is truly down.
- When should I use a circuit breaker?
- After several consecutive failed reconnection attempts (typically 5+) over a long backoff (30+ seconds), assume the database is down and stop trying. Open the circuit breaker and return fast errors to your users so they don't sit staring at spinners. Log the outage and alert your team.
- What is the difference between connection retry and query retry?
- Connection retry fires when the database is unreachable — you're trying to establish a TCP connection. Query retry fires when the connection exists but the query itself fails (e.g. a deadlock or a temporary lock). This diagram shows both paths because they have different backoff strategies.
- How do I customize this for my database?
- Tune the retry count and backoff timing to your SLA. If you need high availability, increase the retry limit to 7–10 and use shorter backoff (500ms → 1s → 2s) so you recover faster. Add a fallback database replica if you have one. Visual edits regenerate clean Mermaid code so you can sketch your connection strategy without syntax.