Architecture & scaling
For databases that have outgrown a single primary.
Scaling MySQL is a sequence of specific decisions — each cheap to get right early and expensive to retrofit. We design and build the pieces in the order your workload actually needs them.
Replication topology
Async, semi-sync, or Group Replication; how many replicas, where, and what each is for. We design topologies around the failure you are protecting against and the staleness your reads can tolerate — and we make lag measurable before it becomes a paging matter.
Read scaling and proxy layers
Routing reads to replicas safely requires knowing which reads can be stale. We implement read/write splitting with ProxySQL or RDS Proxy, connection pooling that survives failover, and the application conventions that keep "read your own writes" working.
Partitioning and sharding
Native partitioning solves data-lifecycle problems (dropping old data by partition instead of deleting by row); sharding solves write-scale problems, at real cost to application simplicity. We are conservative here on purpose: most teams who think they need sharding need indexes, partitioning, or a bigger instance first — and we will show the arithmetic that says which.
High availability and failover
Failover that works is a property of testing, not of architecture diagrams. We design HA with explicit promotion procedures, fencing against split-brain, and scheduled failover drills — because the first unplanned failover should never be the first failover.
Every design lands as written architecture your team owns, with the reasoning attached. If you want the same engineers to build it, that is the same engagement, continued.