How Go powered our elastic search
summary
Form3 replaces heavy Postgres reads with a production Go microservice that consumes SQS -> Elasticsearch events, maps JSONB-rich Postgres rows into denormalised documents (embedding related admission records), and indexes them with millisecond read times. The system batches ~50/sec, monitors shard health and latency, uses versioning to reject out-of-order updates, and supports replaying data to rebuild projections. Result: operational reads move to Elasticsearch, Postgres load drops and UI queries stay fast within their SLA. Go microservice and replay data from Postgres.
AI-written summary · about
chapters (16)
- 0:00Start
- 2:00Agenda
- 14:59Testing Approach
- 15:31Elastic Search Clients
- 17:46Demo
- 20:21Post a Payment
- 21:37Readmes
- 27:42Reading Documents
- 34:49The Shard Sizing
- 36:22Feature Toggles
- 38:36Performance Graphs
- 42:08For Financial Transactions How Did You Secure Elastic Search for Uh Privacy and Also Prevent Data Leaks
- 48:15Could We Use Elasticsearch as a Primary Data Store
- 49:29Changing the Elasticsearch Document Model
- 49:42Using Elasticsearch
- 53:34Scaling
related talks
47mA Journey to Postgres Productivity with Go
48mBuilding Petabyte-Scale PostgreSQL Deployments
32mA Journey to Postgres Productivity with Go
43mJust Use Postgres.
33mTransitioning from Debezium ElasticSearch to Postgres for Streamlined Resilience
51mScaling Postgres to the next level at OpenAI
06mBeyond NoSQL The Case for Postgres in Read Heavy Workloads
50mScaling Postgres With Some Help from Redis