Architecture
Get the database design right before it's hard to change
You're planning a new system or a migration, and the database choices will be expensive to undo later. I design or review the setup with you, and you get a written design your team can test against. If you want, I build it with you too.
When this is worth it
Design help matters most just before a decision becomes hard to reverse. That's usually one of these:
- A new product or service that needs its own database setup.
- A move to another platform or to a managed service.
- Growth in data or traffic that the current layout won't take.
- An incident that showed a gap in the design.
- A choice between two topologies that your team can't settle.
Architecture services
-
MySQL · MariaDB
MySQL & MariaDB High Availability Design & Build
Replication, Galera or InnoDB Cluster: the topology and the proxies in front of it, designed around how they fail.
-
Aurora MySQL
Aurora MySQL Architecture Review & Build
The whole Aurora layout looked at together, with failover seen from the application's side.
-
ClickHouse
ClickHouse Cluster Design, Review & Build
A ClickHouse cluster laid out for your queries, with a written account of what happens when nodes or Keeper fail.
Design work, a diagnostic or a recovery review?
If one workload is slow or expensive right now, start with the MySQL & Aurora Performance Diagnostic, or with the Aurora MySQL performance and cost diagnostic if you run Aurora. They follow one problem to its cause.
If the setup exists and the question is whether its failover and restores would work, the Availability & Recovery Review looks at those assumptions and recommends validation steps your team runs. If you're planning a version change, the upgrade review is the better fit.
Architecture work is about the shape of the system: the topology, and how it fails and grows. I can also build it. It doesn't replace the other reviews, and I'll tell you if one of them suits your question better.
What you receive
- A written design or review of the topology, with the options I considered and why one won.
- Failure scenarios and the behaviour to expect in each.
- Validation tests to run before you rely on the setup.
- Decisions that still need someone on your side to make them.
- If you want it built: the setup in your environment, handed over with runbooks once your team has seen the failure tests pass.
How it runs
- We agree what's in scope and set an effort limit.
- I review whatever your team can share about the system.
- I write up the design or review and walk your technical owner through it.
- If a build is agreed, I set it up with your team and hand it over once the failure tests pass.
Scope, deliverables, effort limit, fee and schedule are agreed in writing before work begins.
Fixed fee, agreed after a short scope review.
Not included
- Running the system after handover: managed operations, on-call cover or emergency response.
- Guarantees about availability or recovery time.
- Application code changes.
Questions
Do you build the cluster as well?
Yes. Once the design is agreed, the build is scoped and priced in writing, like the design. I set it up with your team, using the access you grant and your change approval. Running it afterwards stays with you.
Can you review a design we already have?
Yes. Send what exists, even if it's a whiteboard photo and a list of servers. The review says what holds up, what doesn't and what to test.
Do you work with managed services like Aurora?
Yes. A managed service takes some decisions out of your hands, and the work focuses on the ones that are left. On Aurora those are mostly about endpoints and capacity.
Is this for an incident happening now?
No. This is scheduled work. If a system is failing now, your on-call team or your platform provider's support is the right first contact.
Planning a database change you can't easily undo?
Outline the system, what you're planning and the decision you need to make. A few sentences are enough for a first message.