Bereinigte Produktionsfallstudie
Weiterentwicklung der Backend-Architektur eines KI-gestützten Beschaffungssystems
Trennung von Request-Verarbeitung, Hintergrundprozessen und Unternehmensintegrationen in einem produktiven Python-System.
Das System unterstützt Beschaffungsabläufe mit Lieferantenangeboten, Angebotsvergleich, Verhandlung und Automatisierung des Einkaufsprozesses. Dabei sind sowohl automatisierte als auch menschlich überwachte Abläufe möglich.
Kontext
Als das Beschaffungssystem über seine erste Version hinauswuchs, benötigten API-nahe Abläufe, ressourcenintensive Verarbeitung und externe Integrationen klarere Grenzen. Die Architekturarbeit zielte darauf, Request-Services reaktionsfähig zu halten und gleichzeitig lange laufende operative Abläufe zu unterstützen.
Meine Rolle
Ich habe die Backend-Architektur mitgestaltet und entwickle das System kontinuierlich weiter. Dabei trage ich Verantwortung für API- und Service-Grenzen, die Architektur der Hintergrundverarbeitung, Performance-Verbesserungen, Wartung und neue Backend-Funktionen.
Engineering-Herausforderungen
01
Lange laufende Arbeit im API-Request
Ressourcenintensive Operationen beanspruchten API-Ressourcen und beeinträchtigten die Verfügbarkeit der Request-Services.
02
Zuverlässigkeit externer Systeme
Unternehmens- und ERP-Integrationen mussten vorübergehende Fehler tolerieren, ohne instabilen externen Datenverkehr durch die Anwendung weiterzugeben.
03
Ressourcenverhalten in Produktion
Wiederkehrende Neustarts und Verlangsamungen erforderten Analysen anhand von Anwendungslogs sowie Laufzeit- und RAM-Metriken, einschließlich Ressourcenbindung in Cache- und Dokumentverarbeitung.
Architekturentscheidungen
Die zentrale Entscheidung bestand darin, lange laufende Verarbeitung vom synchronen API-Lebenszyklus zu trennen und die Zuständigkeiten für Request-Verarbeitung, Hintergrundarbeit und Integrationen klarer abzugrenzen.
Schwere Arbeit in Hintergrundprozesse verlagern
Lange laufende Operationen wurden aus synchronen API-Requests in Background Worker verlagert. Die Verarbeitung konnte asynchron verfolgt werden, während Request-Services und ressourcenintensive Workloads getrennte Ausführungsgrenzen erhielten.
Klarere Service-Grenzen definieren
API-nahe Zuständigkeiten, Hintergrundverarbeitung und Agenten-Workflow wurden mit der Weiterentwicklung bewusster getrennt. Neue Funktionen konnten so ergänzt werden, ohne alle Belange an den Request-Pfad zu koppeln.
Vereinfachter konzeptioneller Ablauf
Zuverlässigkeit und Integrationen
Resilienz gegenüber externen Systemen wurde als Bestandteil der Backend-Architektur behandelt.
- Wiederverwendbare Integrationskomponenten für SAP, TOTVS/Datasul und Protheus.
- Wiederholungsversuche bei vorübergehenden Fehlern, Rate Limiting und Circuit Breaker für externe Kommunikation.
- Produktionsanalyse anhand von Anwendungslogs sowie Laufzeit- und RAM-Metriken.
- Containerisierte Hintergrund-Workloads auf AWS ECS.
Ergebnis
- Bessere Trennung zwischen Request-Verarbeitung und ressourcenintensiver Verarbeitung.
- Verbesserte Verfügbarkeit und Stabilität der Services.
- Klarere Grenzen für Wartung und Erweiterung des Backends um neue Funktionen.
Engineering-Urteilsvermögen
Lange laufende Workloads sollten nicht unnötig mit Request-APIs um Ressourcen konkurrieren. Mit wachsender Anwendung werden Service-Grenzen und Resilienz gegenüber externen Integrationen zu Architekturthemen. Produktionslogs und Laufzeitmetriken sind entscheidend, um Fehler in der Anwendungslogik von Problemen im Ressourcenlebenszyklus zu unterscheiden.