Das Backend ist produktiv relevant.
Ausfälle, lange Antwortzeiten oder fehlerhafte Verarbeitung wirken sich direkt auf Kunden, Umsatz oder interne Abläufe aus.
Alle Leistungen
Backend-Entwicklung
Backends die unter Last halten. Nicht nur im Lasttest.
Peak-Traffic ist kein Zufall. Er kommt, zum Kampagnenstart, zum Saisonpeak, zum Ausfall des Wettbewerbers. Ich baue Backends für SaaS-Produkte und Plattformen, die diesen Moment überstehen: in Go und PHP 8, event-getrieben auf AWS, mit Mandantentrennung und Wiederanlauf im Entwurf statt im Nachtrag.
Golang & PHP 8AWS Certified Solutions Architect – Professional20+ Jahre Backend
Was Sie bekommen
- Architektur und Service-Schnitt, der zu Ihren Domänen passt statt zu einem Buzzword
- Produktionsreifer Code mit Tests, Pipeline und Deployment-Strategie
- Lasttests mit belastbaren Zahlen. Sie wissen danach, was das System aushält
- Monitoring, Alarme und Runbooks, mit denen Ihr Team den Betrieb führt
Umfang & Zusammenarbeit
Typischer Umfang 3–9 Monate, Teil- oder Vollzeit. Ein Architektur- oder Lastreview geht auch als abgeschlossenes Zwei-Wochen-Mandat.
Remote aus Deutschland. Direkt mit mir, ohne Agentur dazwischen.
Die Ausgangslage
Es läuft. Bis der Traffic kommt.
Die meisten Backends sind nicht falsch gebaut, sondern für eine andere Größenordnung gebaut. Was mit zehntausend Nutzern funktioniert kippt bei einer Million an Stellen die vorher niemand auf dem Schirm hatte: ein Datenbank-Lock, ein synchroner Aufruf in einer Schleife, ein Connection Pool der zu klein dimensioniert ist.
Dazu kommt der zweite Effekt: Systeme unter Last fallen nicht als Ganzes aus, sie werden langsam. Timeouts stapeln sich, Retries verstärken die Last, aus einem Engpass wird ein Totalausfall. Dagegen hilft kein größerer Server, sondern ein Entwurf der Rückstau aushält.
Typische Symptome- Deployments passieren nachts, weil sie tagsüber zu riskant sind.
- Ein langsamer Downstream-Service reißt das ganze System mit.
- Es gibt keine Zahl dafür, wie viel Last das System verträgt.
- Ein großer Kunde beeinflusst die Antwortzeiten aller anderen.
- Jede Integration an der API wird zum Sonderfall.
- Nur eine Person versteht den kritischen Pfad wirklich.
Für wen das passt
Für Produktteams, deren Backend Umsatz, Nutzer oder kritische Abläufe trägt.
Das Angebot richtet sich an CTOs, technische Leiter und Produktverantwortliche mit einem laufenden digitalen Produkt. Last, Zuverlässigkeit oder technische Altlasten begrenzen die nächste Wachstumsstufe – gesucht wird Architektur plus Umsetzung.
Die Herausforderung liegt unter der Oberfläche.
Datenmodell, Schnittstellen, Parallelität oder Betrieb sind wichtiger als eine weitere sichtbare Funktion.
Ihr Team braucht operative Verstärkung.
Sie suchen keinen Architekturbericht für die Schublade, sondern jemanden, der Entscheidungen im Code und in Produktion mit umsetzt.
Was ich mache
Entworfen.
Belastbar.
Übergeben.
01
Lastprofil und Engpassanalyse
Bevor Code entsteht klären wir, was das System aushalten muss: Requests pro Sekunde, Verhältnis von Peak zu Durchschnitt, Latenzbudget pro Aufruf. Danach messe ich, wo es heute bricht, mit Profiling und Lasttest, nicht mit Vermutungen.
02
Service-Schnitt und Entkopplung
Was nicht synchron sein muss wird asynchron: Queues, Events, idempotente Verarbeitung, Dead-Letter-Queues für den Fall der Fälle. Der Schnitt folgt fachlichen Grenzen und nicht Teamgrenzen. Er entscheidet später über die Betriebskosten.
03
Services in Go für den heißen Pfad
Wo Durchsatz und Latenz zählen ist Go die pragmatische Wahl: kleiner Speicher-Footprint, echte Nebenläufigkeit, schnelle Starts. Bestehendes in PHP bleibt dabei wo es hingehört und wird sauber angebunden, statt alles auf einmal anzufassen.
04
Mandantentrennung und Datenhaltung
Mehrere Kunden auf einer Infrastruktur, ohne dass ein großer Mandant die Antwortzeiten der anderen bestimmt: Isolation auf Daten- und Lastebene, Indizes und Query-Pfade die mitwachsen, Caching als bewusste Entscheidung statt als Abkürzung.
05
Lastfestigkeit und Wiederanlauf
Jeder Aufruf bekommt ein Zeitbudget, jede Abhängigkeit einen Circuit Breaker, jede Last eine Grenze ab der kontrolliert abgewiesen wird. Multi-AZ als Standard, Wiederanlauf und Restore einmal mit gestoppter Uhr geprobt, damit im Ernstfall niemand raten muss.
06
APIs und ruhige Deployments
Die API wird vor der Implementierung spezifiziert. OpenAPI für REST, Protobuf für gRPC, damit Integrationen ohne Rückfragen gelingen. Dazu CI/CD mit Tests, Blue/Green-Deployments, Feature Flags für riskante Änderungen und ein Rollback der geübt ist. Ein Release soll ein Nicht-Ereignis sein.
Einzelfälle
SaaS-Plattform bauenMandantentrennung, Abrechnung und Wiederanlauf entscheiden sich am Anfang, nicht beim zehnten Kunden. Eigene Seite zu dem, was eine SaaS-Plattform trägt, wenn ein Kunde so groß wird wie alle anderen zusammen.Onlineshop entwickelnDer Shop ist selten das Schwere. Schwer ist, was daran hängt: Warenwirtschaft, Kasse, Filialbestände in Echtzeit. Eigene Seite dazu, wann sich ein eigener Shop lohnt und wann eine Standardlösung reicht.Observability einführenWenn Ausfälle von Kunden gemeldet werden statt vom System – oder wenn es umgekehrt zweihundert Dashboards gibt und trotzdem keine Antwort. SLOs an den Geschäftswegen, Alarme mit Adressat, Kardinalität und Kosten entschieden statt gewachsen. Eigene Seite dazu.Deployment-Pipeline bauenWenn Releases in der Nacht liegen und niemand die Strecke anfassen will, die den Code in Produktion bringt. Ein Artefakt durch alle Stufen, Zugänge ohne Langzeitschlüssel, ein Rückweg, der geprobt ist statt beschrieben. Eigene Seite dazu.Go-Services neben PHPKein Rewrite und kein Sprachwechsel: Ein heißer Pfad wird herausgelöst und läuft als Go-Dienst neben dem Bestand weiter. Eigene Seite dazu, wann das trägt und wann der Engpass woanders liegt.
Ihr Backend soll den nächsten Peak überstehen?
Lassen Sie uns in 30 Minuten über Ihr Lastprofil sprechen.
Ablauf
Vom Lastprofil zum laufenden System.
Kein Wasserfall. Jeder Abschnitt endet mit etwas das Sie in der Hand halten: einer Zahl, einer Umgebung oder einem Release.
SCHRITT 01
Zielbild klären
Was soll das System aushalten, wer betreibt es, was ist gesetzt. 30 Minuten reichen für die Einschätzung ob es passt.
SCHRITT 02
Analyse und Entwurf
Lastprofil, Engpassmessung, Zielarchitektur mit Service-Schnitt. Ergebnis ist ein Plan mit Reihenfolge und Aufwand.
SCHRITT 03
Bauen in Inkrementen
Geliefert wird in Schritten die einzeln in Produktion gehen können. Tests, Pipeline und Terraform entstehen mit, nicht danach.
SCHRITT 04
Härten und übergeben
Lasttest gegen die vereinbarten Zahlen, Wiederanlauf geprobt, Runbooks, Pairing bis der Betrieb ohne mich sitzt.
Das Ergebnis
Was Sie danach haben.
Belastbare Zahlen statt Hoffnung
Sie wissen was Ihr System aushält, wo die nächste Grenze liegt und was es kostet sie zu verschieben.
Ausfälle bleiben lokal
Ein überlasteter Teil zieht den Rest nicht mit. Rückstau wird abgefangen statt weitergereicht.
Ein Betrieb der im Team bleibt
Dokumentierte Entscheidungen, Runbooks und ein Team das weiterbauen kann. Kein Wissen das an einer Person hängt.
Eingesetzte Technologien
Bewährte Tools. Kein Experiment.
Sprachen
- Golang
- PHP 8
- Python
- TypeScript
- SQL
Frameworks
- Symfony
- Laravel
- Slim
- gRPC
Schnittstellen
- REST
- gRPC
- API Gateway
- Webhooks
- GraphQL
Datenbanken
- PostgreSQL
- MySQL
- MariaDB
- Aurora
- DynamoDB
Cache und Queue
- Valkey / Redis
- Elasticache
- SQS
- SNS
- Apache Kafka
Plattform
- ECS Fargate
- EKS
- Lambda
- EventBridge
- Docker
Infrastruktur
- Terraform
- AWS CDK
- GitHub Actions
- GitLab CI
Betrieb
- OpenTelemetry
- CloudWatch
- Datadog
- Grafana
- Prometheus
Mit wem Sie es zu tun haben
Direkt mit mir als Freelancer. Keine Agentur dazwischen.
Ich bin Tim Rutte. Über 20 Jahre Softwareentwicklung, heute baue ich Backends, die unter Last halten und im Fehlerfall vorhersagbar bleiben. Sie sprechen mit der Person, die Ihren Code anfasst, vom ersten Gespräch bis zur Übergabe.
- 20+Jahre Softwareentwicklung
- 50+erfolgreiche Projekte
- 2003seit diesem Jahr remote im Einsatz
Zusammenarbeit
Mitarbeit im Team oder eigenständige Umsetzung.
Sie müssen kein bestimmtes Setup mitbringen. Ich passe die Zusammenarbeit daran an, wie Ihr Unternehmen aufgestellt ist und wie viel Verantwortung Sie abgeben möchten.
01Gemeinsam
Ich arbeite in Ihrem Team.
Wenn Wissen und Verantwortlichkeiten bereits bei Ihnen liegen, steige ich dort ein, wo zusätzliche Erfahrung gebraucht wird. In Ihren Abläufen, mit direkter Abstimmung und ohne Parallelwelt.
- Integration in Ihre Sprints, Reviews und technischen Entscheidungen
- Pairing und Wissenstransfer während der Umsetzung
- Code, Dokumentation und Betrieb bleiben vollständig bei Ihrem Team
02Eigenständig
Ich übernehme die Umsetzung.
Wenn intern Zeit oder Kapazität fehlt, übernehme ich ein klar abgegrenztes Vorhaben von der technischen Klärung bis zum produktiven Einsatz. Sie geben Ziel und Rahmen vor, ich kümmere mich um den Weg dorthin.
- Ein Ansprechpartner von der Klärung bis zur Umsetzung
- Regelmäßige, verständliche Zwischenstände statt laufender Steuerung
- Saubere Übergabe mit Dokumentation und Einweisung
In beiden Modellen gilt: Sie sehen jederzeit, was entsteht, welche Entscheidungen anstehen und was als Nächstes passiert. Abgerechnet wird je nach Projektbedarf und Ihrem bevorzugten Modell: klar abgegrenzte Vorhaben zum Festpreis, längere und dynamische nach Aufwand.
Kontinuität
Ihr System bleibt Ihres.
Auch bei eigenständiger Umsetzung entsteht keine Abhängigkeit von mir. Alles, was für Weiterentwicklung und Betrieb nötig ist, liegt vom ersten Tag in Ihrer Umgebung und wird laufend übergabefähig gehalten.
Zugänge bleiben bei Ihnen.
Code, Cloud-Accounts, Pipelines und Secrets liegen in Ihren Systemen. Der Betrieb hängt nicht an einem persönlichen Konto oder einem Zugang, den nur ich kontrolliere.
Wissen bleibt nicht in meinem Kopf.
Architekturentscheidungen, Betriebsabläufe und bekannte Risiken werden dort dokumentiert, wo Ihr Team sie später findet – und während des Projekts aktuell gehalten.
Ein anderer kann übernehmen.
Reproduzierbare Umgebungen, automatisierte Deployments und regelmäßige Übergaben sorgen dafür, dass Ihr Team oder ein anderer Dienstleister ohne Neustart weiterarbeiten kann.
Das Ziel ist nicht, dass Sie mich dauerhaft brauchen. Das Ziel ist, dass Sie jederzeit frei entscheiden können, wer das System weiterentwickelt.
Kundenstimmen
Was Auftraggeber hinterher sagen.
„Herr Rutte hat für uns ein komplett individuelles CRM entwickelt und dies genau auf unsere Bedürfnisse zugeschnitten. Die Zusammenarbeit war unkompliziert. Er hat unsere Anforderungen perfekt umgesetzt und das System läuft absolut stabil.“
„Tim hat bei uns als PHP-Entwickler gearbeitet und einen richtig guten Job gemacht. Er hat sich schnell ins Projekt eingearbeitet und auch bei kniffligen Themen immer eine Lösung gefunden. Der Code war sauber, nachvollziehbar und hat uns echt weitergebracht. Wir würden jederzeit wieder mit Tim zusammenarbeiten.“
„Die Entwicklung unserer Software wurde wie besprochen fertiggestellt und alle Probleme wurden beseitigt. Vielen Dank.“
Häufige Fragen
Bevor Sie fragen.
Bauen Sie auch das Frontend?
Nein. Ich baue Backend, Schnittstellen und Infrastruktur. Für Frontend und Design arbeite ich mit Ihrem Team oder den Dienstleistern zusammen, die Sie schon haben. Die Abstimmung läuft über den API-Contract, der vorher steht. Wenn Sie jemanden für das komplette Produkt inklusive Oberfläche suchen, bin ich der Falsche und sage das im Erstgespräch.
Müssen wir dafür auf Microservices umstellen?
Nein. Ein gut geschnittener Monolith ist vielen verteilten Systemen überlegen und deutlich billiger im Betrieb. Ich zerlege nur dort wo es einen konkreten Grund gibt: unterschiedliche Lastprofile, unterschiedliche Release-Zyklen oder Teamgrenzen die sonst dauerhaft blockieren.
Brauchen wir Kubernetes?
Oft nicht. Kubernetes ist ein gutes Werkzeug, wenn Sie mehrere Teams, viele Services und Menschen haben die den Cluster betreiben können. Für die meisten Setups ist ECS Fargate schneller am Ziel und günstiger im Betrieb. Ich entscheide das anhand Ihres Teams und Ihrer Last, nicht anhand des Trends.
Warum Go und nicht unsere bestehende Sprache?
Meistens bleibt die bestehende Sprache. Go setze ich gezielt dort ein wo Durchsatz, Latenz und Speicherverbrauch zählen, als zusätzlicher Service neben dem Bestand, angebunden über gRPC oder Queue. Wie das ohne Komplettumbau funktioniert, habe ich in einem eigenen Artikel beschrieben.
Schreiben Sie selbst Code oder beraten Sie nur?
Ich schreibe Code. Der Entwurf entsteht am Anfang, aber der größte Teil der Zeit fließt in Implementierung, Tests und Pipeline. Beratung ohne Umsetzung führt in meiner Erfahrung zu Dokumenten die niemand liest.
Arbeiten Sie mit unserem bestehenden Team zusammen?
Ja, und das ist der Regelfall. Ich arbeite im Pairing, dokumentiere Entscheidungen als ADR im Repository und übergebe bevor ich gehe. Das Ziel ist nicht Abhängigkeit von mir, sondern ein Team das selbst weiterbauen kann.
Begriffe, die hier vorkommen
TestabdeckungRefactoringMonolithMicroservicesAPI FirstAnti-Corruption LayerFeature FlagModularer MonolithExpand and ContractBus-FaktorBrownfield und GreenfieldServerlessAmazon RDSRTO und RPOBlue-Green-DeploymentMulti-TenancyMulti-RegionKubernetesCI/CDLoad BalancerCachingMessage QueueAPI GatewayRESTWebhookDatenbankindexChaos EngineeringRunbookIdempotenzCircuit BreakerRate LimitingObservabilitySLO, SLI und SLAEvent-Driven ArchitectureInfrastructure as CodeGraceful DegradationgRPCSaga-MusterCanary ReleaseShardingWorkflow-OrchestrierungETLERP-AnbindungLeast PrivilegeSecrets ManagementZero TrustAudit-LogVerschlüsselung at Rest und in TransitPatch-ManagementPenetrationstest
Zum GlossarWeitere Leistungen
Womit ich sonst helfe.
Legacy-Modernisierung
Gewachsene Systeme schrittweise modernisieren: Strangler-Fig statt Rewrite, laufender Betrieb unangetastet, jeder Schritt umkehrbar.
Mehr erfahrenAWS-Migration
Vom eigenen Rechenzentrum oder aus einer anderen Cloud nach AWS, mit Kostenmodell vor dem Umzug und Rollback-Pfad für jeden Schritt.
Mehr erfahrenAWS-Kosten senken
Ich finde wo Ihr AWS-Budget versickert, messbar reduziert, ohne Abstriche bei Performance oder Verfügbarkeit.
Mehr erfahrenAWS-Ausfallsicherheit verbessern
Damit ein einzelner Fehler nicht die ganze Anwendung mitnimmt: Abhängigkeiten und Single Points of Failure gefunden, Wiederanlauf geprobt statt dokumentiert, Änderungen als Terraform.
Mehr erfahrenKI-Integration
Die Infrastruktur hinter produktiven KI-Systemen: MCP-Server, sichere Tool-Anbindung, LLM-Integration mit Zugriffsschutz und Kostenkontrolle.
Mehr erfahrenProzessautomatisierung
Manuelle Abläufe durch echte Systeme ersetzen: angebunden an Ihre Bestandssysteme, mit Berechtigungen und Protokoll statt Tool-Kette.
Mehr erfahren