CASE STUDY // 2goredisdatabasehealth-tech

NHS Sidecar: Preventing Database Locks on Transaction Spikes.

How a four-person team built an asynchronous, read-optimized integration sidecar using Go and Redis to handle traffic spikes on clinical records databases.

// THE ARCHITECTURE

Visual system wiring & data flows.

Go queue throttles database writes

Redis cache replica absorbs read traffic spikes

Go queue throttles database writes

Redis cache replica absorbs read traffic spikes

Go queue throttles database writes

// DEPLOYMENT LOG

Timeline logs & incidents.

10:00

Sidecar deployment

Go sidecar active on 4 cluster nodes. Primary transactional database reads rerouted.

14:15

Clinical record batch spike

Sudden upload of 14,000 vaccination records. Connection queues grew.

14:22

Queue draining

Redis cache handled all read requests; Go worker throttled writes to DB, resolving locking issues.

observer@edge

~ % tail -f sidecar.log

› redis: reading state ok

› spiking inputs. worker processing queue

› latency stable at 15ms

Never deploy straight to prod on a Friday without monitoring queue backups.

— postmortem checklist

// WHAT ALMOST BROKE

Honest failure points.

database

Database locks

Legacy EHR locked clinical transactional writes under high spikes. Rerouted reads to a Redis replica.

infrastructure

Unbounded queue

Connection pools melted under batch inserts. Configured a bounded buffer with NATS queue routers.

// LESSONS

The system got smarter because it broke in public.

SYSTEM ARCHITECTURE & POSTMORTEM

1. Situation Context Legacy EHR database locks are the nightmare of health-tech. Spikes in data entries by clinical staff locked the tables, blocking doctor lookups.

2. Why It Was Interesting Clinical databases are highly regulated. Modifying core database configurations is high-risk. We had to build a sidecar system that intercepted reads and writes without affecting the legacy engine schema.

3. What We Built We deployed a Go-based integration sidecar. Reads are resolved by a Redis replica that syncs asynchronously. Writes are queued in a bounded buffer, allowing the database to digest operations at a steady rate. Lookups now run under 15ms p99, and database lockups dropped to zero.

never let reporting tools query your primary transactional database.

— maya

failing fast is better than queue deadlocks.

— atlas

compiling_ecosystem…

Timeline logs & incidents.

10:00

Sidecar deployment

Go sidecar active on 4 cluster nodes. Primary transactional database reads rerouted.

14:15

Clinical record batch spike

Sudden upload of 14,000 vaccination records. Connection queues grew.

14:22

Queue draining

Redis cache handled all read requests; Go worker throttled writes to DB, resolving locking issues.

The system got smarter because it broke in public.

SYSTEM ARCHITECTURE & POSTMORTEM

1. Situation Context Legacy EHR database locks are the nightmare of health-tech. Spikes in data entries by clinical staff locked the tables, blocking doctor lookups.

2. Why It Was Interesting Clinical databases are highly regulated. Modifying core database configurations is high-risk. We had to build a sidecar system that intercepted reads and writes without affecting the legacy engine schema.

3. What We Built We deployed a Go-based integration sidecar. Reads are resolved by a Redis replica that syncs asynchronously. Writes are queued in a bounded buffer, allowing the database to digest operations at a steady rate. Lookups now run under 15ms p99, and database lockups dropped to zero.