Residents and clerks need ranked full-text search across municipal code, ordinances, and permit conditions, currently implemented as slow SQL LIKE queries on the permitting RDS database that also serves OLTP. Which architecture should replace that search path?
Select an answer to reveal the explanation.
Short Explanation
LIKE '%plumbing%' on the billing database is a flashlight in a warehouse. OpenSearch is the card catalog built for ranked full-text search, and it keeps those queries off the OLTP box. Replicas of the same SQL habit still aren't a search engine.
Full Explanation
Residents and clerks needing ranked full-text search across municipal code, ordinances, and permit conditions—currently implemented as slow SQL LIKE queries on the permitting RDS database that also serves OLTP—should index that text in Amazon OpenSearch Service rather than using RDS LIKE as the search engine. Offloading search protects billing/OLTP latency and delivers ranked relevance for civic research. Adding more RDS read replicas and keeping LIKE '%term%' as the public search engine fails relevance quality and still burdens relational replicas with scan-like patterns. Scanning Amazon CloudWatch Logs Insights for ordinance text at query time fails because logs are not the system of record for municipal code. Storing every ordinance as a single Amazon EBS snapshot and grepping it from a bastion fails scale, concurrency, and citizen UX. Exam caveat: full-text ranked search belongs in OpenSearch (or similar), not OLTP LIKE. Operational check: export code and permit text to an OpenSearch index, secure the domain, wire the portal search UI, load-test ranked queries, and stop LIKE searches on the OLTP RDS endpoint. Document the decision in the municipal architecture decision record and re-verify controls after the first production wave so auditors see continuous improvement, not one-time tribal knowledge.