Peak traffic is not an accident. It arrives, with the campaign launch, the seasonal peak, the competitor’s outage. I build backends for SaaS products and platforms that survive that moment: in Go and PHP 8, event-driven on AWS, with tenant isolation and recovery designed in rather than bolted on.
Typical scope is three to nine months, part time or full time. An architecture or load review also works as a self-contained two week engagement.
Remote from Germany. Straight with me, no agency in between.
Most backends are not built wrong, they are built for a different order of magnitude. What works with ten thousand users tips over at a million in places nobody had on their radar: a database lock, a synchronous call inside a loop, a connection pool sized too small.
Then comes the second effect: systems under load do not fail all at once, they get slow. Timeouts stack up, retries amplify the load, and a bottleneck turns into a total outage. No bigger server fixes that. Only a design that absorbs backpressure does.
Typical symptomsBefore any code, we establish what the system has to take: requests per second, the ratio of peak to average, the latency budget per call. Then I measure where it breaks today, with profiling and a load test rather than assumptions.
What does not have to be synchronous becomes asynchronous: queues, events, idempotent processing, dead letter queues for when it matters. The split follows domain boundaries rather than team boundaries, because it determines your operating cost later.
Where throughput and latency matter, Go is the pragmatic choice: small memory footprint, real concurrency, fast starts. Existing PHP stays where it belongs and gets connected cleanly, rather than everything being touched at once.
Several customers on one infrastructure, without one large tenant dictating response times for the others: isolation at the data and load level, indexes and query paths that scale with you, and caching as a deliberate decision rather than a shortcut.
Every call gets a time budget, every dependency a circuit breaker, every load level a point beyond which it gets shed deliberately. Multi-AZ as standard, recovery and restore rehearsed once against the clock, so nobody has to guess when it counts.
The API gets specified before it gets implemented, OpenAPI for REST and Protobuf for gRPC, so integrations succeed without follow-up questions. Plus CI/CD with tests, blue/green deployments, feature flags for risky changes, and a rollback that has been practised. A release should be a non-event.
No waterfall. Every stage ends with something you can hold: a number, an environment or a release.
What the system has to take, who runs it, what is already fixed. 30 minutes is enough to tell whether it fits.
Load profile, bottleneck measurement, target architecture with service boundaries. The result is a plan with an order and an effort estimate.
Delivered in steps that can go to production individually. Tests, pipeline and Terraform grow with it, not after it.
Load test against the agreed numbers, recovery rehearsed, runbooks, pairing until operations run without me.
You know what your system takes, where the next limit sits, and what it costs to move it.
An overloaded part does not drag the rest down. Backpressure gets absorbed rather than passed on.
Documented decisions, runbooks and a team that can keep building. No knowledge tied to one person.
No. I build the backend, the interfaces and the infrastructure. For frontend and design I work with your team or the people you already use, and the coordination runs through the API contract, which is agreed up front. If you are looking for someone to deliver the complete product including the interface, I am the wrong person and I will say so in the first call.
No. A well-structured monolith beats plenty of distributed systems and is considerably cheaper to run. I split things only where there is a concrete reason: different load profiles, different release cycles, or team boundaries that would otherwise block permanently.
Often not. Kubernetes is a good tool when you have several teams, many services and people who can run the cluster. For most setups ECS Fargate gets there faster and costs less to operate. I decide that based on your team and your load, not on the trend.
Usually the existing language stays. I use Go deliberately where throughput, latency and memory footprint matter, as an additional service next to what you have, connected over gRPC or a queue. I have written up how that works without a rebuild in a separate article.
I write code. The design happens at the start, but most of the time goes into implementation, tests and the pipeline. In my experience, advice without implementation produces documents nobody reads.
Yes, and that is the normal case. I work in pairs, document decisions as ADRs in the repository, and hand over before I leave. The goal is not dependence on me, it is a team that can keep building on its own.
The infrastructure behind AI systems that actually ship: MCP servers, controlled tool access, LLM integration with real permissions and cost control.
Learn moreReplacing manual workflows with real systems: wired into the software you already run, with permissions and an audit log instead of a chain of tools.
Learn moreI find where your AWS budget leaks away, and cut it measurably without giving up performance or availability.
Learn moreFrom your own data centre or another cloud onto AWS, with a cost model before the move and a rollback path for every step.
Learn moreModernizing grown systems step by step: strangler fig instead of a rewrite, operations untouched, every step reversible.
Learn more