Inside a DevOps Team Extension engagement: an infrastructure review and a Typesense architecture session

Qovery’s DevOps Team Extension engagement with an unnamed growing B2B SaaS company began with a read-only review of roughly 150 infrastructure controls across three AWS EKS clusters, identifying sound foundational practices but gaps in Kubernetes workload alerting, redundancy, production isolation, database exposure, shared credentials, and burstable database capacity. A joint review with the customer corrected several automated findings, uncovered configuration and Terraform isolation issues that API checks could not detect, and highlighted the absence of service criticality classifications as the most valuable strategic finding. The team agreed on a 90-day plan covering alerting, database improvements, safer preview-environment cleanup, internal-tool access controls, and a review of production service resilience. A proposed three-node high-availability Typesense cluster was successfully tested but ultimately reconsidered after discussion revealed that search was noncritical because the application could fall back to PostgreSQL, while memory capacity—not availability—was the main constraint. The recommendation therefore shifted to application-level logical sharding across smaller independent Typesense instances, limiting outages to subsets of customers, reducing memory costs compared with full dataset replication, and allowing selected customers to receive dedicated high-availability clusters if needed.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.