Overview
Hotel searches initially read from the SQL database that also supported core operations. Growing search traffic increased pressure on that shared read path.
The challenge
Search needed its own read path without querying the primary SQL database on every request. MongoDB data also had to follow source changes, with a possible synchronization delay.
Technical approach
The AWS Lambda endpoint reads search data from MongoDB. Changes from SQL flow through CDC, Debezium, and Kafka to the Go sync-to-mongo worker, which writes to the MongoDB read model separately from search requests.
Follow the data
Two separate paths run below. Select a technology to pause and inspect its role.
Search request
Guest
A guest sends a hotel search request.
Search requests read MongoDB, not the primary SQL database on every request.
Data synchronization
SQL
Hotel data changes in the source SQL database.
The event flow updates the search read model separately. A synchronization delay is possible.
Conceptual architecture · no production traffic, timing, or internal data shown
My contribution
Developed the AWS Lambda search endpoint and the Go worker in sync-to-mongo that processes Kafka events into MongoDB as part of a team.
Architecture outcome
Search requests use a dedicated read path from AWS Lambda to MongoDB. Source updates reach that search read model through a separate event flow, so each search does not have to query the primary SQL database directly. This describes the architecture, not a measured performance gain.
Data synchronization is event based. A change in SQL may take time to appear in MongoDB.