5 exercises — practise the English vocabulary for database incident communication: replication lag, deadlock identification, connection pool exhaustion, failover vs. switchover, and WAL-based crash recovery.
0 / 18 completed
1 / 18
During an active incident, the on-call engineer posts in the incident channel: "We are seeing 45-second replication lag on the read replica." What does this mean for read-heavy services currently pointing at that replica?
Replication lag vocabulary:
Option C is the correct operational impact. Replication lag is the delay between when a transaction commits on the primary and when that change is applied on the replica.
Term
Definition
Replication lag
Delay between primary commit and replica apply
Stale read
A read that returns outdated data because the replica has not yet applied recent writes
Read-after-write consistency
Guarantee that a user can always read their own recent write — broken under replication lag
Replica promotion
Elevating a replica to primary — during high lag, this risks losing recently committed data
Incident communication vocabulary for replication lag:
"We are routing all read traffic back to the primary to avoid stale reads until lag is resolved."
"The replica is currently 45 seconds behind — services that require read-after-write consistency should not query it."
"Lag has been stable at 45 seconds for 10 minutes — investigating whether this is WAL volume, network throughput, or replica I/O saturation."
Common causes to investigate: long-running transactions on primary, high WAL volume, replica I/O bottleneck, network link saturation between primary and replica.
2 / 18
The application logs show recurring deadlocks on the orders table. Which incident message most effectively communicates this situation to an on-call team that includes both engineers and a product manager?
Deadlock incident communication vocabulary:
Option B is the model incident message because it covers five elements: what is happening (deadlocks), why (lock acquisition order conflict), who is affected (product manager can understand "3–5% of checkout requests failing"), current state (being retried), and action plan (consistent lock ordering fix).
Deadlock vocabulary:
Term
Plain English definition
Deadlock
Two transactions each hold a lock the other needs — neither can proceed; the database kills one
Victim transaction
The transaction the database rolls back to resolve the deadlock
Lock acquisition order
The sequence in which a transaction requests locks — inconsistent order across transactions causes deadlocks
Deadlock retry
Application-level logic to re-execute a rolled-back transaction after a deadlock
Standard deadlock fix vocabulary for PRs:"The fix ensures both the checkout and inventory update transactions acquire the orders row lock before the inventory row lock, eliminating the circular wait condition."
3 / 18
An SRE reports: "The database connection pool is exhausted — all 100 connections are active, new queries are queuing, and response time is climbing." Which action is the correct immediate mitigation for connection pool exhaustion?
Connection pool exhaustion vocabulary and mitigation:
Option C is the correct immediate mitigation. Restarting the primary (Option A) causes additional downtime and risks data loss — it is never the first response. Increasing max_connections alone (Option B) does not free stuck slots and must account for PostgreSQL's per-connection memory overhead. Adding a read replica (Option D) does not help when write connections are exhausted.
Prevents the pool from over-requesting connections relative to the DB limit
Enable PgBouncer (connection pooler)
Multiplexes many app connections into fewer physical DB connections
Add idle_in_transaction_session_timeout
Auto-kills transactions idle in an open BEGIN — the most common exhaustion culprit
Key terms:
Connection pool — a cache of pre-established database connections shared across application threads
Pool exhaustion — all connections are active; new requests queue or fail with "too many connections"
PgBouncer / pgpool — middleware that multiplexes many logical connections into fewer physical database connections
idle in transaction — a connection holding an open BEGIN with no active query; holds locks and wastes a connection slot indefinitely
4 / 18
During a database incident, the primary server fails and the monitoring system automatically promotes the standby to primary in 12 seconds. The on-call engineer needs to communicate this to stakeholders. Which term correctly describes this process, and which message is most appropriate?
Database failover vocabulary:
Option D is correct on both counts. A failover is an automatic or manual response to a primary failure, in contrast to a switchover which is a planned, controlled role change.
Term
Triggered by
Data loss risk?
Failover
Primary failure (unplanned)
Possible if standby was lagging at failure time
Switchover
Planned maintenance (controlled)
No — standby is caught up before role swap
Promotion
The act of elevating a replica to primary
—
RTO (Recovery Time Objective)
Max acceptable time to restore service
—
RPO (Recovery Point Objective)
Max acceptable data loss (measured in time)
—
Why Option D's message is correct:
Names the event precisely: "unexpected failure" (vs. vague "went down")
Gives the exact time: "15:42 UTC" — critical for incident timeline reconstruction
States the current status clearly: "database is now operational"
Provides the next update time — prevents stakeholders from flooding the channel with "what's happening?"
5 / 18
After a database crash, a DBA says: "We need to check the WAL to determine the last committed transaction before the crash so we can assess any data loss." What is the WAL and why is it critical for database recovery?
WAL vocabulary and crash recovery:
Option C is the correct and precise definition. The Write-Ahead Log (WAL) is the foundation of database durability — the D in ACID.
WAL crash recovery process:
After a crash, PostgreSQL enters recovery mode at startup
It reads the WAL from the last checkpoint forward
Redo: committed transactions whose data pages were not yet written to disk are replayed and applied
Undo: partial (uncommitted) transactions are rolled back
The database reaches a consistent state and opens for connections
Term
Definition
WAL (Write-Ahead Log)
Append-only log of all changes, written before data pages — ensures durability
Checkpoint
A point where all dirty pages up to that LSN are guaranteed written to disk; limits WAL replay on recovery
LSN (Log Sequence Number)
Position in the WAL stream — used to identify exactly where replication or recovery is up to
WAL archiving
Saving WAL segments to external storage for point-in-time recovery (PITR)
PITR (Point-in-Time Recovery)
Restoring the database to an exact moment using a base backup + WAL segments
6 / 18
PR Description:
During a recent incident impacting order processing, the development team created this PR description:
"Investigating high latency. SQL query `SELECT * FROM orders WHERE status = 'pending'` is timing out consistently. Initial investigation suggests index missing on `status` column."
This option presents the information most clearly and effectively for a PR description. It directly links the technical problem (slow query timing out) to its impact on the business – order processing – and specifies the *immediate* required action (adding an index). The other options either oversimplify the situation, suggest less targeted solutions (scaling up), or fail to connect the technical detail to the real-world consequences.
7 / 18
During a database incident involving slow query performance, a developer writes the following comment on a code review: 'This query is running really slowly. It's probably because we're not using an index.' Which of the following statements best describes what this comment suggests and why it's relevant to the incident?
Option A: The developer is suggesting that the entire database schema needs a complete redesign.
Option B: The developer suspects a missing index could be causing performance issues, and further investigation into query execution plans is warranted.
Option C: The developer is blaming the application code for inefficient query design.
Option D: The developer believes the database server itself is under-resourced and needs more RAM.
The developer's comment highlights a common cause of slow SQL queries: lack of appropriate indexes. Indexes dramatically speed up data retrieval by creating a lookup table for frequently queried columns. The incorrect options misinterpret the situation – a redesign isn't immediately necessary, blaming the code is premature without investigation, and server resource issues are possible but less likely given the specific comment. This reflects a critical understanding of SQL optimization techniques during incident response.
8 / 18
PR Description:
During a recent incident impacting order processing, the development team created this PR description:
"Investigating high latency. SQL query `SELECT * FROM orders WHERE status = 'pending'` is timing out consistently. Initial investigation suggests index missing on `status` column."
This option presents the information most clearly and effectively for a PR description. It directly links the technical problem (slow query timing out) to its impact on the business – order processing – and specifies the *immediate* required action (adding an index). The other options either oversimplify the situation, suggest less targeted solutions (scaling up), or fail to connect the technical detail to the real-world consequences.
9 / 18
During a database incident involving slow query performance, a developer writes the following comment on a code review: 'This query is running really slowly. It's probably because we're not using an index.' Which of the following statements best describes what this comment suggests and why it's relevant to the incident?
Option A: The developer is suggesting that the entire database schema needs a complete redesign.
Option B: The developer suspects a missing index could be causing performance issues, and further investigation into query execution plans is warranted.
Option C: The developer is blaming the application code for inefficient query design.
Option D: The developer believes the database server itself is under-resourced and needs more RAM.
The developer's comment highlights a common cause of slow SQL queries: lack of appropriate indexes. Indexes dramatically speed up data retrieval by creating a lookup table for frequently queried columns. The incorrect options misinterpret the situation – a redesign isn't immediately necessary, blaming the code is premature without investigation, and server resource issues are possible but less likely given the specific comment. This reflects a critical understanding of SQL optimization techniques during incident response.
10 / 18
PR Description:
During a recent incident impacting order processing, the development team created this PR description:
"Investigating high latency. SQL query `SELECT * FROM orders WHERE status = 'pending'` is timing out consistently. Initial investigation suggests index missing on `status` column."
This option presents the information most clearly and effectively for a PR description. It directly links the technical problem (slow query timing out) to its impact on the business – order processing – and specifies the *immediate* required action (adding an index). The other options either oversimplify the situation, suggest less targeted solutions (scaling up), or fail to connect the technical detail to the real-world consequences.
11 / 18
During a database incident involving slow query performance, a developer writes the following comment on a code review: 'This query is running really slowly. It's probably because we're not using an index.' Which of the following statements best describes what this comment suggests and why it's relevant to the incident?
Option A: The developer is suggesting that the entire database schema needs a complete redesign.
Option B: The developer suspects a missing index could be causing performance issues, and further investigation into query execution plans is warranted.
Option C: The developer is blaming the application code for inefficient query design.
Option D: The developer believes the database server itself is under-resourced and needs more RAM.
The developer's comment highlights a common cause of slow SQL queries: lack of appropriate indexes. Indexes dramatically speed up data retrieval by creating a lookup table for frequently queried columns. The incorrect options misinterpret the situation – a redesign isn't immediately necessary, blaming the code is premature without investigation, and server resource issues are possible but less likely given the specific comment. This reflects a critical understanding of SQL optimization techniques during incident response.
12 / 18
PR Description:
During a recent incident impacting order processing, the development team created this PR description:
"Investigating high latency. SQL query `SELECT * FROM orders WHERE status = 'pending'` is timing out consistently. Initial investigation suggests index missing on `status` column."
This option presents the information most clearly and effectively for a PR description. It directly links the technical problem (slow query timing out) to its impact on the business – order processing – and specifies the *immediate* required action (adding an index). The other options either oversimplify the situation, suggest less targeted solutions (scaling up), or fail to connect the technical detail to the real-world consequences.
13 / 18
During a database incident involving slow query performance, a developer writes the following comment on a code review: 'This query is running really slowly. It's probably because we're not using an index.' Which of the following statements best describes what this comment suggests and why it's relevant to the incident?
Option A: The developer is suggesting that the entire database schema needs a complete redesign.
Option B: The developer suspects a missing index could be causing performance issues, and further investigation into query execution plans is warranted.
Option C: The developer is blaming the application code for inefficient query design.
Option D: The developer believes the database server itself is under-resourced and needs more RAM.
The developer's comment highlights a common cause of slow SQL queries: lack of appropriate indexes. Indexes dramatically speed up data retrieval by creating a lookup table for frequently queried columns. The incorrect options misinterpret the situation – a redesign isn't immediately necessary, blaming the code is premature without investigation, and server resource issues are possible but less likely given the specific comment. This reflects a critical understanding of SQL optimization techniques during incident response.
14 / 18
Sarah, a database engineer, is drafting a Slack message to alert the on-call team about an unexpected spike in query execution time. The logs show a significant increase in the duration of queries against the `users` table. Which of the following phrases would be MOST effective in conveying this urgency and requesting immediate investigation?
'We've noticed some performance issues with the users table. Please investigate.'
Option 0 clearly states the problem (high volume of queries), its impact (system responsiveness), and the required action (investigate ASAP). Options 1 & 2 are too vague. Option 3 is incorrect advice – rebooting isn't a solution to performance issues and could cause further problems. This phrasing uses precise technical language suitable for an incident response.
15 / 18
Mark, a developer, is writing a PR description for a change that addresses a recent database incident where users were unable to complete orders. The PR includes a new SQL query optimized for performance. Which of the following statements best describes the information Mark should include in his PR description to communicate effectively with reviewers and stakeholders?
'This PR optimizes the SELECT * FROM orders WHERE status = 'pending' query to improve response times.'
Option 0 directly relates the change (optimized SQL query) to the *cause* of the incident (latency impacting order processing). This provides context for reviewers. Options 1 & 2 are too broad – they don't explain the connection between the code change and the problem. Option 3 is simply a technical description lacking crucial information about the root cause.
16 / 18
During a database incident, Alex, an SRE, notices that the database connection pool is completely exhausted. The system is reporting 'queueing' and increasing response times. Which of the following explanations would be MOST appropriate to provide to the development team during a stand-up update?
'The database server is overloaded due to excessive concurrent connections.'
Option 1 accurately describes the situation – connection pool exhaustion leading to performance degradation. It uses clear and accessible language suitable for a non-technical audience. Options 2 & 3 are misdiagnoses of the problem. Option 4 is possible but doesn't explain *why* the application is sending requests.
17 / 18
The monitoring system detects a database replica experiencing 45-second replication lag. As David, a database engineer, you need to explain this to the application team. Which of the following statements is MOST effective in communicating the severity and potential impact?
'Replication lag is normal; it's just a slight delay.'
Option 1 clearly states the problem (replication lag), its *impact* (stale data being served to users) and the required action (immediate investigation). Options 2 & 3 are downplaying the severity. Option 4 is a technical definition without conveying the potential consequences.
18 / 18
During a database incident, Lisa, a DBA, discovers that the WAL (Write-Ahead Log) is corrupted. Which of the following statements BEST describes why this is critical to understand and how it affects database recovery?
'The WAL contains records of all database transactions; its corruption prevents us from reconstructing the database state.'
Option 0 accurately explains the function of the WAL (recording transactions for durability) and how corruption impacts recovery – it prevents point-in-time reconstruction. Options 1 & 2 are partially correct but miss the crucial element of *recovery*. Option 3 & 4 are incorrect.
What does the "Database Incident Language" exercise practise?
Practice English for database incident communication: replication lag, deadlocks, connection pool exhaustion, failover vocabulary, and WAL crash recovery terminology. 5 advanced exercises.
How many questions are in this exercise?
This exercise has 18 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Advanced. If the vocabulary feels difficult, browse the Database & SQL category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Database Incident Language" part of a larger series?
Yes — it's one exercise in the Database & SQL category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Database & SQL category page for related exercises, or browse the main Exercises hub for other IT English topics.