🏗️ Wo sollte nativer Code liegen? Phalcon, Symfony und TrueAsync auf verschiedenen Ebenen des Stacks.

vom 27. Juni 2026

Seit Jahren ist Phalcon eine rationale Antwort für stark frequentierte PHP-Plattformen: ein Framework, das als C-Erweiterung bereitgestellt wird, mit geringem Ressourcenverbrauch und einer vertrauten MVC-Architektur.

Kürzlich stieß ich im Rahmen eines Proof-of-Concept-Architekturprojekts für einen Kunden auf eine Situation, die typisch für ausgereifte PHP-Plattformen ist: eine leistungsstarke, bestehende Infrastruktur, Wartungsbeschränkungen, Workflows, die komplexer geworden sind als der einfache Anfrage-Antwort-Zyklus, und die Versuchung, schnell ein Framework auszuwählen. Die naheliegende Frage war: Sollten wir beim Phalcon-Modell bleiben oder auf Symfony aufbauen? Die eigentliche Frage ging jedoch tiefer: Wo sollten native Performance, Geschäftslogik und Workflow-Orchestrierung angesiedelt sein?

Phalcon, Symfony und TrueAsync stehen nicht in direkter Konkurrenz zueinander: Sie optimieren unterschiedliche Anforderungen auf verschiedenen Ebenen des Stacks. Dieser Artikel geht von dieser praktischen Beobachtung aus, um eine umfassendere Perspektive zu bieten – ohne dabei anzunehmen, dass Migration immer die richtige Lösung ist.

Einleitung – Die Frage lautet nicht mehr: „Welches Framework ist schneller?“

Dieser Machbarkeitsnachweis war kein Einzelfall. Auf leseintensiven Plattformen reduziert sich das Dilemma oft auf zwei Optionen: Phalcon auf der einen Seite – eine C-Erweiterung mit geringem Overhead und bewährtem MVC-Architekturmuster – und Symfony auf der anderen Seite – ein Ökosystem, eine etablierte Struktur und einfachere Rekrutierung – mit TrueAsync im Hintergrund als Versprechen asynchroner Laufzeitumgebung. Jede dieser Optionen hatte ihre Vorzüge. Keine beantwortete jedoch die sich allmählich herauskristallisierende Frage: Auf welcher Ebene sollte die Performance optimiert und auf welcher die Orchestrierung erfolgen?

Die Diskussion ging schnell über die Wahl des Frameworks hinaus. Sollten wir bei einer Architektur ähnlich wie Phalcon bleiben, bei der der native Code auf der MVC-Ebene liegt? Oder zu Symfony migrieren, um Wartbarkeit und Interoperabilität zu verbessern? TrueAsync als Laufzeit-Option einführen, unabhängig von der Webentwicklungsentscheidung? Oder die Framework-Migration mit der Neugestaltung von Arbeitsabläufen verwechseln – der häufigste Fehler, den wir auf dieser Art von Plattform beobachten?

Die Ausgangsfrage lautete: „Sollten wir von Phalcon zu Symfony migrieren?“ Die grundlegende Frage lautete: Wo sollte der native Code liegen – und wo sollten die Schnittstellen und Geschäftsprozesse angesiedelt sein?

Für den Muttersprachler existieren drei Reaktionsmöglichkeiten nebeneinander, jede auf einem anderen Niveau:

• Framework-Schicht - Phalcon optimiert Router, Dispatcher, ORM und Cache über eine C-Erweiterung
• Anwendungsschicht - Symfony strukturiert die Anwendung in reinem PHP: Dependency Injection, Sicherheit, Bundles, Organisationskonventionen
• Laufzeitschicht - TrueAsync zielt auf gleichzeitige Ausführung und nicht-blockierende E/A über ext-async ab.

Diese drei Ansätze schließen sich nicht gegenseitig aus. Der Proof of Concept (POC) offenbarte jedoch vor allem einen vierten Bereich, der in Debatten um „Framework A vs. Framework B“ oft übersehen wird: Wo Workflows angesiedelt sind und wie sich Geschäftslogik vom zugehörigen Ausführungsmodell trennen lässt. Abgrenzungen, Orchestrierung und Laufzeit sind drei unabhängige Entscheidungen. Werden diese – wie die ursprüngliche Projektformulierung nahelegte – vermischt, führt dies zu den teuersten und ineffektivsten Migrationen.

Bei Darkwood versuchen wir, folgende Perspektive einzunehmen: Die Branche optimiert Frameworks seit Langem; komplexe Systeme offenbaren nun einen weiteren Engpass – die Definition von Grenzen und die explizite Orchestrierung. Die native Laufzeitumgebung bleibt ein Implementierungsdetail, nicht die Architektur. Der folgende Artikel verallgemeinert die Erkenntnisse dieses Proof of Concept und formuliert eine Perspektive, die über einen spezifischen Anwendungsfall hinaus gültig ist.

Warum Phalcon sinnvoll war – und es immer noch ist

Phalcon ist ein Full-Stack-PHP-Framework mit kompiliertem Kern. Es ist in Zephir (https://phalcon.io) geschrieben und wird über das cphalcon-Projekt (https://github.com/phalcon/cphalcon) nach C transpiliert. Die Verwendung entspricht der anderer PHP-Frameworks: Controller, Services und Module. Der Unterschied liegt im Stack: Eine HTTP-Anfrage erreicht PHP-FPM, die Erweiterung ist bereits geladen, und die kritischen Primitiven – Router, Dispatcher, ORM und Cache – befinden sich in der nativen Schicht. Die Geschäftslogik verbleibt in PHP; das Framework-Gerüst wird vorgelagert optimiert.

Für Redaktions-, Medien- oder E-Commerce-Plattformen bleiben die Vorteile mit dem richtigen Profil deutlich spürbar. Geringer Overhead durch den MVC-Ansatz. Konsistentes Modell: Module, Dependency Injection, ORM, PHQL, Volt, Cache. Leseintensive APIs mit vorab berechneten Dokumenten. Monolithische Architektur mit mehreren Schnittstellen ohne zusätzliche Schichten.

Phalcon war nicht „moderner“ als Symfony. Es war genau dort besser geeignet – auf Framework-Ebene – für ein bestimmtes Workload-Profil. Und für Teams, die diesen Stack beherrschen, ihre SLOs erfüllen und deren Produkt sich kaum weiterentwickelt, ging dieser Vorteil nicht über Nacht verloren.

Phalcon im Jahr 2026: Wartung, Management, Glaubwürdigkeit

Eine unvoreingenommene Lektüre von Phalcon im Jahr 2026 beginnt mit den Fakten – nicht mit der Annahme eines sich verschlechternden Rahmens.

Der 5.x-Zweig wird aktiv gepflegt. Version 5.16.0 wurde im Juni 2026 nach einem beschleunigten Release-Zyklus im zweiten Quartal veröffentlicht. Commits im Zweig 5.0.x erfolgen häufig; das Changelog dokumentiert wesentliche Änderungen: die Schicht Phalcon\Contracts, einen neuen DI-Container, eine Authentifizierungskomponente, eine Queue-Schicht (Beanstalk, Redis, Memory, Stream), PIE-Unterstützung für die Installation, Migration zu Zephir 1.0 und Qualitätssicherungstools (Infection, Sonar). Dies ist weit mehr als die minimale Wartung eines statischen Projekts.

Das Ökosystem verfügt über eine nachweislich solide und glaubwürdige Grundlage. Die Datei BACKERS.md im cphalcon-Repository listet die Unterstützer aus der Branche auf – darunter Cloudflare (auch auf der Cloudflare-Sponsoringseite erwähnt), Algolia und DigitalOcean (eine dokumentierte Open-Source-Partnerschaft für Benchmarks und Infrastruktur). Open Collective und GitHub-Sponsoren leisten einen bescheidenen, aber realen Beitrag zur Community-Finanzierung. Die Steuerung basiert auf einem fokussierten Kernteam unter der Leitung von Nikolaos Dimopoulos und Anton Vasiliev mit strukturierten Beitragsprozessen.

Diese Faktoren beweisen nicht, dass Phalcon „besser“ als Symfony ist. Sie beweisen aber, dass es sich nicht um ein verlassenes Ökosystem handelt. Ein Sponsor aus der Industrie ist keine technische Garantie; er ist ein Zeichen dafür, dass das Projekt weiterhin sichtbar ist und von Stakeholdern unterstützt wird, die an seine langfristige Tragfähigkeit glauben.

Architektonisch gesehen bleibt cphalcon im Kern Zephir/C: über tausend .zep-Dateien, die als Erweiterung über PIE oder PECL verteilt werden. Die nächste Hauptversion ist in Vorbereitung und gehört zum Zweig 7.0.x (PHP 8.3+), nicht zu einem v6-Zweig in diesem Repository. Öffentliche Diskussionen und die Arbeit an einem zugehörigen PHP-Repository („phalcon/phalcon“) deuten auf eine Weiterentwicklung hin zu einem zweigleisigen Modell: eine Referenzimplementierung in PHP mit optionalen Erweiterungen für die ressourcenintensivsten Bereiche – ermittelt durch Messungen. Dies ist eine architektonische Weiterentwicklung, keine Verdrängung der nativen Implementierung.

Die Tabelle ermittelt keinen Gewinner. Sie stellt Bedingungen dar.

Phalcon ist nicht veraltet – das Optimierungsziel hat sich geändert.

Die falsche Frage lautet: „Ist Phalcon veraltet?“ Die richtige Frage lautet: „Welche Optimierung ist jetzt am wichtigsten?“

Lange Zeit waren die Prioritäten klar:

• Reduzierung der Kosten des MVC-Dispatch- und Bootstrap-Frameworks
• Minimierung des Speicher- und CPU-Overheads auf dem Anfrage-Antwort-Pfad
• Bereitstellung leseintensiver APIs von einem hochperformanten Monolithen ohne Vervielfachung der Laufzeiten

Phalcon ging diese Prioritäten konsequent an. Das native Framework war der richtige Hebel.

Die Prioritäten haben sich verändert – nicht weil Phalcon etwas „übersehen“ hätte, sondern weil die Systeme gewachsen sind und sich die Engpässe verlagert haben:

• Verteilte Komplexität - Message-Busse, Worker, abgeleitete Modelle, groß angelegte Cache-Invalidierung
• E/A-Engpässe - HTTP-Aggregation, Dateien, Netzwerkwartezeiten in Workern, nicht nur Bootstrap-Zeit
• Orchestrierung – Handler-Ketten, Cronjobs, CLI-Skripte: Workflow-Logik umgeht MVC
• Onboarding und Interoperabilität - Rekrutierung, Pakete, Sicherheitsstandards, Integrationen von Drittanbietern
• Organisatorische Skalierbarkeit - abgegrenzte Kontexte, progressive Extraktion, Koexistenz von Stacks

Auf vielen ausgereiften Plattformen ist der native Router nicht mehr der entscheidende Flaschenhals. Vielmehr sind es blockierende E/A-Vorgänge in Workern, die Komplexität von Arbeitsabläufen oder der Wartungsaufwand. Diese Verschiebung – nicht eine Wertung – verändert die Diskussion um die Architektur.

Phalcon bleibt relevant, solange der synchrone MVC-Ansatz die wichtigste Einschränkung darstellt und das Team den Stack gut beherrscht. Symfony gewinnt an Relevanz, wenn die Codeorganisation und das Ökosystem über einen Zeitraum von zehn Jahren im Vordergrund stehen. TrueAsync kommt zum Einsatz, wenn Laufzeit-E/A-Wartezeiten die wichtigste Einschränkung darstellen – unabhängig vom gewählten Framework.

Wo sollte der native Code liegen?

Kehren wir zur zentralen Frage zurück. Drei Ebenen, drei Logiken:

flowchart TB
  subgraph layers [Couches de la pile PHP]
    FrameworkLayer["Couche framework\nPhalcon extension C"]
    AppLayer["Couche application\nSymfony structure"]
    RuntimeLayer["Couche runtime\nTrueAsync ext-async"]
  end
  Question["Où vit le code natif ?"]
  Question --> FrameworkLayer
  Question --> AppLayer
  Question --> RuntimeLayer

Phalcon und TrueAsync teilen eine intuitive Vorgehensweise – kritische Aufgaben näher an den nativen Code heranzuführen –, aber nicht das gleiche Problem. Phalcon optimiert den Einstieg in das Framework. TrueAsync optimiert das Warten in der Geschäftslogik. Symfony hingegen konzentriert sich nicht auf das native Framework, sondern auf Struktur und Interoperabilität.

Die Platzierung von nativem Code ist eine Architekturentscheidung, keine Modefrage. Man kann nativen Code auf der Framework-Ebene haben, ohne nativen Code zur Laufzeit zu verwenden. Man kann nativen Laufzeitcode einführen, ohne Phalcon aufzugeben. Man kann seine Architektur in Symfony auch ohne TrueAsync strukturieren. Die Kombinationen hängen von wohlüberlegten Einschränkungen ab – nicht von einer „alt vs. neu“-Erzählung.

Symfony – eine weitere Optimierung, kein universeller Ersatz

Symfony bietet eine solide strukturelle Grundlage: HttpKernel, Routing, Dependency Injection, Sicherheit, Konsole, Cache, Messenger, Doctrine-Integration und ausgereifte Tools. Für eine Plattform, die ihren Code über Jahre hinweg dokumentieren, prüfen und weiterentwickeln muss, ist es eine verlässliche Organisationsgrundlage.

Das Argument ist nicht nur technischer Natur. Es ist auch organisatorischer Natur: einfachere Rekrutierung, umfangreiche Dokumentation, Standardintegrationen, eine klare Entwicklungsrichtung über mehrere PHP-Versionen hinweg, ohne auf eine für jedes Upgrade kompilierte Framework-Erweiterung angewiesen zu sein.

Symfony optimiert jedoch eine andere Einschränkung als Phalcon. Es verspricht keinen Router in C. Es verspricht eine wartbare, testbare und integrierbare Anwendung – mit einem Ökosystem, das einen Großteil der übergreifenden Komplexität (Authentifizierung, Warteschlangen, Observability, Validierung) aufnimmt.

Symfony ist die richtige Antwort, wenn die dominierenden Kosten nicht mehr die Mikrosekunde des MVC-Bootstrap sind, sondern:

• die Liefergeschwindigkeit für ein Produkt in der Evolution
• die Fähigkeit, Personal zu rekrutieren und auszubilden
• Integration mit externen Diensten und Standards
• die Klarheit der Anwendungsbereiche auf lange Sicht

Symfony ist nicht automatisch besser. Es handelt sich um eine weitere Optimierung – und die damit verbundenen Migrationskosten sollten nicht unterschätzt werden.

TrueAsync – native, experimentelle, nicht-automatische Laufzeitumgebung

TrueAsync spielt eine dritte Rolle, unabhängig von der Wahl des Frameworks. Es handelt sich um eine experimentelle PHP-Erweiterung (ext-async), eine Engine-Integration, einen libuv-Scheduler, Koroutinen und nicht-blockierende Ein-/Ausgabe für bekannte Funktionen (curl, Dateien, in einigen Fällen PDO). Die API bietet spawn(), await() und delay() – ohne dabei jede Funktion im Code als asynchron zu kennzeichnen.

Wir sollten hinsichtlich der Reife von TrueAsync vorsichtig bleiben. TrueAsync ist experimentell: PHP 8.6+, individuelle Anpassung, sich entwickelnde API, RFC in Arbeit. Es ist weder ein offizieller PHP-Standard noch ein direkter Ersatz für Swoole oder Amp. Es ist auch nicht „die Zukunft“ von PHP – es ist eine Richtung, die anhand konkreter Anwendungsfälle evaluiert werden muss.

TrueAsync lässt sich sowohl hinter einem Phalcon-Monolithen als auch hinter Symfony implementieren. Die native Laufzeitumgebung erfordert keine Framework-Migration. Synchrone CRUD-Operationen im Backend sind in der Regel nicht erforderlich. Bei E/A-intensiven Prozessen, parallelen HTTP-Aggregationen und Dateipipelines kann TrueAsync jedoch sinnvoll sein, wenn die Metriken dies rechtfertigen und eine benutzerdefinierte Version akzeptabel ist.

Bei Darkwood betrachten wir TrueAsync als Ausführungsstrategie – je nach Kontext austauschbar – und nicht als grundlegende Architekturentscheidung. Architektur definiert den Workflow und seine Grenzen. Der asynchrone Treiber legt lediglich die Art und Weise der Ausführung fest.

Wann man Phalcon nicht verlassen sollte

Migration ist nicht immer wünschenswert. Manche Teams sollten auf Phalcon bleiben – und das ist eine rationale Entscheidung, kein Eingeständnis des Scheiterns.

Übernachten Sie, wenn:

Das Team beherrscht Phalcon und die Produktivität ist hoch. Die Kosten für das erneute Erlernen und Überarbeiten übersteigen den erwarteten Nutzen.

• Die Service-Level-Objectives (SLOs) – Latenz, Durchsatz, Stabilität – wurden erreicht, und die Lastprofile haben sich nicht grundlegend verändert.
• Das Produkt wird nur wenig weiterentwickelt – Fehlerbehebungen, Wartung, keine grundlegenden Überarbeitungen oder zahlreiche Ökosystemintegrationen.
• Migrationskosten > Geschäftswert – Überarbeitungen, doppelte Ausführungen, Regressionsrisiko, monatelanger Funktionsstopp.
• Eine schrittweise Modernisierung ist ausreichend – Upgrade auf Phalcon 5, Einführung von PIE, Verwendung neuer Komponenten (Queue, Container, Contracts) ohne Änderung des Frameworks

In solchen Fällen ist die Migration zu Symfony nur, weil „es alle anderen auch tun“, ein strategischer Fehler. Phalcon v5 im Jahr 2026 ist nicht dasselbe wie Phalcon 3, das auf PHP 7 feststeckt: Das Projekt entwickelt sich weiter, das Ökosystem wird unterstützt, und das native Framework bleibt so lange relevant, wie es den Flaschenhals darstellt.

Vier mögliche Flugbahnen

Für eine groß angelegte PHP-Plattform sind vier Lösungen plausibel – keine davon ist standardmäßig die „richtige“:

1. Bei Phalcon bleiben und modernisieren. Upgrade auf Version 5, neue Komponenten einführen, interne Workflows refaktorisieren und die Beobachtbarkeit verbessern. Optional TrueAsync für E/A-intensive Worker, falls der benutzerdefinierte Build akzeptabel ist.

2. Migration zu Symfony. Wenn Ökosystembeschränkungen, Personalbeschaffung oder Produktentwicklung im Vordergrund stehen. Schrittweise Migration (wie ein Strangulator), kein abrupter Wechsel. TrueAsync ist in einer späteren Phase optional.

3. Hybridarchitektur. Phalcon verarbeitet kritischen Datenverkehr oder APIs mit sehr geringer Latenz; Symfony kümmert sich um neue, abgegrenzte Kontexte oder sich entwickelnde Schnittstellen. Dies ist eine bewusste Koexistenz mit expliziten API-Verträgen zwischen den beiden Welten.

4. Führen Sie die native Laufzeitumgebung unabhängig vom Framework ein. TrueAsync (oder eine asynchrone Alternative) auf Workern und I/O-Pipelines, ohne das Web-Framework zu modifizieren. Phalcon oder Symfony in der HTTP-Schicht; die asynchrone Laufzeitumgebung in der Ausführungsschicht.

TrueAsync ist in keinem Pfad außer dem vierten automatisch Teil der Antwort – und selbst dann erst nach der Messung. Es ist keine Voraussetzung für die Migration.

Grenzen vor Rahmenwerken

Hier ist die These, die wir bei Darkwood vertreten und die wir in fast allen Architekturprojekten wiederfinden: Viele „Framework-Migrationen“ sind eigentlich Probleme schlecht definierter Grenzen.

Ein veralteter Monolith leidet nicht immer unter einem langsamen Router. Vielmehr liegt das Problem darin, dass drei Geschäftssprachen ohne klare Abgrenzung nebeneinander existieren: Empfang (Ereignisse empfangen und validieren), Veröffentlichung (Speichern und Benachrichtigen) und Lesen (optimierte Ansicht bereitstellen). Im Code nutzen diese drei Funktionen dieselben Handler, dieselben Dienste und dieselben Cron-Skripte. Ein Framework-Wechsel ohne Neudefinition dieser Grenzen verschiebt das Problem lediglich.

Mehrere Konzepte helfen uns, dieses Problem zu benennen – ohne den Artikel in einen DDD-Katalog zu verwandeln:

Abgegrenzte Kontexte. Jeder Geschäftsbereich hat sein eigenes Vokabular und seine eigenen Invarianten. Auf einer Redaktionsplattform hat „veröffentlichter Artikel“ auf der Verarbeitungsseite (dem zu verarbeitenden Ereignis) und auf der Leseseite (dem vorab berechneten Dokument, das ausgeliefert werden soll) unterschiedliche Bedeutungen. Die Zusammenführung beider in einem einzigen Modul führt zu den verschachtelten Handlern, die wir überall sehen.

Domänendienste vs. Anwendungsdienste. Geschäftsregeln (z. B. Inhaltsvalidierung, Berechnung des Veröffentlichungsstatus) sollten nicht im selben Bereich wie die technische Koordination (z. B. Cache-Invalidierung, Busaufruf, Neuerstellung eines Lesemodells) implementiert werden. Wenn alles als „Dienst“ behandelt wird, lässt sich nichts isoliert testen.

Orchestrierungsschicht vs. Domänenschicht. Die Orchestrierungsschicht steuert die einzelnen Schritte; die Domäne entscheidet. „Speichern, dann ungültig machen, dann neu erstellen“ ist Orchestrierung. „Ist dieser Inhalt veröffentlichungsfähig?“ ist Domäne. Werden beide in einem Controller oder Message-Handler vermischt, ist eine unabhängige Verwaltung unmöglich.

CQRS und Lesemodelle. Auf leseintensiven Plattformen unterliegen Schreibpfad (kanonischer Speicher) und Lesepfad (abgeleitete Modelle, Cache, aggregierte Dokumente) gegensätzlichen Anforderungen. Die Verwendung einer einzigen ORM-Schicht für beide Pfade führt zu kostspieligen Kompromissen. Die explizite Trennung von Schreib- und Lesepfad ist kein Dogma, sondern eine natürliche Reaktion auf ein analysiertes Arbeitslastprofil.

Ereignisgesteuerte und ereignisgesteuerte Konsistenz. Nach der Persistenz können Cache-Invalidierung und Lesemodellrekonstruktion asynchron erfolgen. Dies ist akzeptabel, vorausgesetzt, die Grenze zwischen starker und ereignisgesteuerter Konsistenz ist klar definiert.

flowchart TB
  subgraph sync_boundary [Boundary synchrone]
    Validate[Validation]
    Persist[Persistence canonique]
    Validate --> Persist
  end
  subgraph async_boundary [Boundary eventual]
    Invalidate[Invalidation]
    Rebuild[Rebuild read model]
    Invalidate --> Rebuild
  end
  Persist -->|"événement"| Invalidate

Der synchrone Grenzwert – Validierung und Persistenz – muss den ACID-Prinzipien entsprechen: Entweder wird der Inhalt akzeptiert und gespeichert, oder der Vorgang schlägt sauber fehl. Der potenzielle Grenzwert – Ungültigmachung und Rekonstruktion – kann eine Verzögerung tolerieren, sofern das lesende System dies akzeptiert (z. B. durch einen Mechanismus zur Verarbeitung veralteter Daten).

Bei der Prüfung einer Plattform im Hinblick auf eine Migration lautet die erste Frage nicht: „Phalcon oder Symfony?“ Sondern: Wo verlaufen die Grenzen heute und wo sollten sie verlaufen? Das Framework ist lediglich ein Container. Ein sauberer, aber schlecht designter Container ist immer noch besser als ein gut designter, der dieselben geschäftlichen Probleme birgt.

PEFT-Archetyp – Leseintensive redaktionelle Plattform – Muster

Um die Argumentation zu verankern, ohne uns an eine reale Architektur zu halten, stellen wir uns die PEFT (High Traffic Editorial Platform) vor – einen Archetyp, keinen Kundenfall.

PEFT vereint Funktionen, die für große Content-Plattformen typisch sind:

• Dominanter Lesepfad - APIs und das öffentliche Web liefern vorab berechnete Ansichten, nicht die aktuelle relationale Datenbank.
• Ereignisgesteuerte Datenerfassung – Ein vorgelagertes System sendet Veröffentlichungsereignisse; Worker verarbeiten, validieren und speichern diese.
• Abgeleitete Modelle - nach Persistenz, Ungültigmachung und Rekonstruktion optimierter Lesestrukturen (Cache, aggregierte Dokumente)
• Multi-Surface-Monolith – Web, APIs und Stapelverarbeitung teilen sich eine Codebasis, die oft in Modulen organisiert ist.
• Progressive Extraktion – einige abgegrenzte Kontexte beginnen sich zu lösen, aber der Kern trägt weiterhin einen erheblichen Teil des Datenverkehrs.

flowchart LR
  CMS[Source de contenu] --> Bus[Bus de messages]
  Bus --> Workers[Workers ingestion]
  Workers --> Store[(Stockage canonique)]
  Workers --> Cache[(Modèles dérivés)]
  Cache --> APIs[APIs read-heavy]
  APIs --> Clients[Clients]

Betrachtet man PEFT aus der Perspektive von Grenzen, so offenbart es drei implizite abgegrenzte Kontexte:

1. Erfassung – Empfangen, Validieren und Normalisieren eingehender Ereignisse
2. Veröffentlichung – den kanonischen Zustand aufrechterhalten, Signale des Wandels aussenden
3. Lesen – Bereitstellung optimierter Lesemodelle, unabhängig vom Schreibschema

Das CQRS-Muster ist hier naheliegend: Kanonische Speicher (Schreibmodell) und abgeleitete Modelle (Lesemodelle) haben unterschiedliche Lebenszyklen. Ungültigmachung und Rekonstruktion führen zu einer angenommenen potenziellen Konsistenz zwischen Schreiben und Lesen – akzeptabel, solange die SLOs für Aktualität explizit definiert sind.

Bei diesem Archetyp basieren architektonische Entscheidungen nicht auf der Wahl des Routers. Sie basieren auf Folgendem:

• wo die Logik der Datenaufnahme und -invalidierung angesiedelt ist (verschränkte Handler vs. explizite Arbeitsabläufe)
• wo die Grenze zwischen Domäne und Orchestrierung verläuft
• ob der Flaschenhals im synchronen MVC-Prozess oder in der E/A der Worker liegt.
• wenn das Produkt eine umfassende Reorganisation oder eine lange Stabilisierungsphase erfordert.

PEFT kann auf Phalcon bleiben, solange die SLOs erfüllt werden und das Team stabil ist. PEFT kann zu Symfony migrieren, wenn das Ökosystem und die Fluktuation dies erfordern. PEFT kann hybrid betrieben werden. TrueAsync kommt nur dann zum Einsatz, wenn die Worker-I/O zum messbaren Flaschenhals wird – unabhängig vom Framework. In jedem Fall muss jedoch die Grenzen neu definiert werden, bevor die Technologiewahl getroffen wird.

Erkenntnisse - Drei Archetypen von People of Color

Der in der Einleitung erwähnte Proof of Concept – eine stark frequentierte PHP-Plattform, performanter Legacy-Code und Workflows, die über das MVC-Modell hinausgehen – veranschaulicht einen ersten Archetyp. Er ist nicht der einzige. In unserer Beratungs- und Validierungstätigkeit begegnen wir regelmäßig drei Profilen, bei denen der richtige erste Schritt selten vom Framework abhängt. Er hängt vielmehr von der Art der dominanten Altlasten ab.

Archetyp 1 – Legacy-Monolith, komplexe Geschäftsregeln. Dies trifft auf den ersten Proof of Concept zu: eine ausgereifte Plattform, komplexe Geschäftslogik und wenig Spielraum für Überarbeitungen. Der sinnvolle Ansatz bestand nicht darin, Phalcon und Symfony theoretisch zu vergleichen, sondern die impliziten Kontextgrenzen abzubilden, die Grenzen der synchronen Konsistenz zu identifizieren und eine schrittweise Extraktion (Strangler) für jeden Kontext vorzuschlagen. Das Framework – Phalcon oder Symfony – trat in den Hintergrund: Die Herausforderung bestand darin, die Geschäftsregeln aus dem Labyrinth der Handler zu extrahieren.

Archetyp 2 – Greenfield Symfony. Neues Produkt, wachsendes Team, zahlreiche geplante Integrationen. Hier lag der Fokus auf Domänenmodellierung und klar definierten Modulen – nicht asynchron, nicht in der nativen Laufzeitumgebung. Wir haben die Grenzen frühzeitig festgelegt (Domänendienste, Anwendungsdienste, separate Leseschichten), um in Symfony nicht das Spaghetti-artige Geflecht zu erzeugen, vor dem wir anderswo geflohen waren. Messenger reichte für die ersten Workflows aus; explizite Orchestrierung war erst mit zunehmender Komplexität erforderlich.

Archetyp 3 – Automatisierung und E/A-intensive Workflows. Verarbeitungsketten (Inhaltsanreicherung, mehrere API-Aufrufe, Dateipipelines – Profile ähnlich einigen KI-Ketten). Der Flaschenhals war nicht der Router oder das Domänenmodell, sondern die E/A-Wartezeit und das Fehlen eines expliziten Ausführungsmodells. Wir haben den Workflow zunächst lesbar gemacht – Schritte benannt, Fehler isoliert, synchrone/asynchrone Grenzen definiert – und erst dann je nach Umgebung TrueAsync, Amp oder Fiber evaluiert. Die Einführung der asynchronen Laufzeitumgebung vor einem expliziten Workflow hätte das eigentliche Problem verschleiert.

Diese drei Archetypen führen nicht zum gleichen Vorgehen. Sie teilen jedoch eine gemeinsame Vorgehensweise: Die dominante Einschränkung analysieren, bevor die Technologie ausgewählt wird. Genau das wenden wir bei Darkwood an – sowohl bei Phalcon als auch bei Symfony, mit oder ohne TrueAsync.

Orchestrierung als Hauptanliegen

Web-Frameworks wie Phalcon, Symfony und Laravel sind für einen einzigen Zyklus optimiert: HTTP-Anfrage → Verarbeitung → Antwort. Das ist ihre Stärke. Gleichzeitig ist es aber auch ihre Schwäche.

Ausgereifte Systeme wachsen schnell über diesen Zyklus hinaus. Ein Veröffentlichungsereignis löst eine Kette aus: Validierung, Persistenz, Cache-Invalidierung, Rekonstruktion des Lesemodells, Benachrichtigung und Bestätigung an einen Bus. Diese Kette lässt sich nicht in einem Controller kapseln. Sie ist fragmentiert über Message-Handler, Dienste, CLI-Skripte und Cronjobs verteilt – manchmal über Jahre der Entwicklung, manchmal unter dem Druck von Produktionsbereitstellungen, bei denen Geschwindigkeit Vorrang vor Struktur hatte.

Wir bezeichnen dies als ein Orchestrierungsproblem: die explizite Koordination von Geschäftsprozessen, die über den Anfrage-Antwort-Zyklus hinausgehen. Und wir sind der Ansicht, dass dieses Problem die gleiche architektonische Aufmerksamkeit verdient wie die Wahl des Frameworks.

Eine workflowzentrierte Architektur ersetzt nicht das MVC-Modell, sondern ergänzt es. Der Controller bleibt granular: Er empfängt, delegiert und antwortet. Der Workflow trägt die mehrstufige Logik: Er benennt die Schritte, behandelt Fehler in jedem Schritt, definiert Konsistenzgrenzen und trennt – idealerweise – die Pipeline-Beschreibung vom Ausführungsmodell.

Hier unterscheiden wir uns von den Ansätzen „Alles in Messenger“ oder „Alles in einem übergeordneten Dienst“. Messenger übermittelt Nachrichten; es orchestriert nicht nativ eine mehrstufige Pipeline mit austauschbaren Ausführungsstrategien. Ein 800-zeiliger Dienst, der alles orchestriert, ist zwar möglich, aber undurchsichtig und nicht testbar.

Bei Darkwood betrachten wir Orchestrierung als ebenso wichtig wie Schnittstellen und Framework-Auswahl. Nicht etwa, weil ein einzelnes Tool alles lösen könnte, sondern weil das Vernachlässigen der Orchestrierung die häufigste Ursache für gescheiterte Migrationen ist. Man wechselt das Framework, die Handler bleiben verstrickt, und die Schulden bleiben bestehen.

Ablauf – Trennung des Workflows vom Ausführungsmodell

Diese Beobachtung veranlasste uns zur Entwicklung von Flow – einer Open-Source-Komponente, nicht eines Ersatz-Frameworks.

Flow existiert, weil wir bei Migrationen in der Praxis immer wieder dasselbe Muster beobachtet haben: Workflow-Logik findet in Symfony oder Phalcon keinen natürlichen Platz. Sie landet in anonymen Handlern, Cron-Skripten oder Sammeldiensten. Flow gibt ihr einen architektonischen Platz: eine explizite Pipeline, bestehend aus Flow (dem Schritt), Job (dem Unit-Job) und Ip (dem Datentoken, das die Pipeline durchläuft).

Das wichtigste architektonische Unterscheidungsmerkmal ist für uns jedoch DriverInterface.

Gleicher Arbeitsablauf. Austauschbares Ausführungsmodell.

Eine Veröffentlichungspipeline – Validierung, Speicherung, Ungültigmachung, Neuaufbau – kann rein synchron, mit PHP Fibers, Amp-Coroutinen, einer ReactPHP-Ereignisschleife, einem Swoole-Worker oder über TrueAsync ausgeführt werden. Die Geschäftslogik bleibt unverändert. Nur das Ausführungsmodell ändert sich. Dies ist eine Infrastrukturentscheidung, keine Domänenentscheidung.

Flow bietet derzeit mehrere Treiber an: FiberDriver (Standard, keine Erweiterung), AmpDriver, ReactDriver, SwooleDriver, SpatieDriver, ParallelDriver und TrueAsyncDriver (experimentell, ext-async). Jeder Treiber ist für einen anderen Anwendungsfall geeignet – bestehende Integration, dedizierter Worker, experimentelle native Ein-/Ausgabe.

use Flow\Driver\FiberDriver;
use Flow\Driver\TrueAsyncDriver;
use Flow\Flow\Flow;
use Flow\Ip;

// Le workflow est stable ; seul le driver change selon l'environnement
$driver = TrueAsyncDriver::isSupported()
    ? new TrueAsyncDriver()
    : new FiberDriver();

$flow = (new Flow(job: new ValidateMessage(), driver: $driver))
    ->fn(new Persist())            // domaine : boundary synchrone
    ->fn(new InvalidateCache())    // orchestration
    ->fn(new RebuildReadModel());  // I/O potentiellement async

$flow(new Ip($message));
$flow->await();

Symfony empfängt das Ereignis – über Messenger oder einen internen Endpunkt – und leitet es an Flow weiter. Jede fn()-Funktion stellt einen benannten Schritt dar; Fehler können mit errorJob isoliert werden. TrueAsync wird nicht zuerst verwendet: FiberDriver ist der Standardwert, misst die Situation und wählt dann diejenige Pipeline aus, die dies rechtfertigt.

Wichtige Punkte für den Produktiveinsatz: FiberDriver und TrueAsyncDriver dürfen nicht im selben Prozess verwendet werden (TrueAsync blockiert Userland Fibers, solange es aktiv ist). Threads, Kanäle oder TaskGroups sollten nicht von Anfang an eingeführt werden – dies erhöht die Betriebskomplexität unnötig.

Flow ist nicht die einzige Lösung. Symfony Messenger, eine benutzerdefinierte Pipeline oder ereignisgesteuerte Orchestrierung können für einfache Workflows ausreichen. Flow verfolgt einen ambitionierteren Ansatz: Orchestrierung wird zu einem grundlegenden Architekturelement, mit einer expliziten Trennung zwischen dem Was (der Pipeline) und dem Wie (dem Treiber).

Wir behaupten nicht, dass Flow die Zukunft ist. Wir sagen aber, dass explizite Orchestrierung – mit der Möglichkeit, die Ausführungsstrategie zu ändern, ohne die Geschäftslogik neu zu schreiben – eine Richtung ist, die uns komplexe Systeme gelehrt haben, ernst zu nehmen.

Wenn Sie sich für eine Migration entscheiden – Prinzipien, kein Handlungsplan

Wenn man sich für den Weg „Migration zu Symfony“ entscheidet – und nur dann – sind einige wenige Prinzipien besser als ein starrer Fünf-Phasen-Plan.

Erst messen, dann umziehen. Identifizieren Sie die tatsächlichen Engpässe: MVC, Workflows, I/O-Worker, Volt/PHQL-Kopplung, unscharfe Schnittstellen. Migrieren Sie kein leistungsstarkes Framework, um ein Orchestrierungs- oder Modellierungsproblem zu lösen.

Definieren Sie zuerst die Grenzen neu. Bevor Sie ein Modul neu schreiben, benennen Sie dessen abgegrenzte Kontexte, Lesemodelle und Konsistenzgrenzen. Der Strangler arbeitet kontextbezogen, nicht schichtweise.

Strangler statt Big Bang. Neue Symfony-Anwendung parallel; progressives Routing Endpunkt für Endpunkt. API-Verträge bleiben während der Koexistenz erhalten.

Erst synchron, dann asynchron. Extrahieren Sie die Workflows synchron. Sorgen Sie für eine lesbare und testbare Abfolge, bevor Sie TrueAsync oder eine andere asynchrone Laufzeitumgebung einführen.

Asynchrone Verarbeitung aktivieren. TrueAsync nur bei E/A-intensiven Pipelines in einer dedizierten Umgebung, mit der Möglichkeit zum Fallback.

Legacy-Muster werden je nach ihrer Art unterschiedlich migriert: Kettenhandler werden in einen expliziten Workflow integriert; Anwendungsmodule in Bundles oder Feature/-Ordner; Ad-hoc-Cache-Invalidierung in eine benannte Pipeline; blockierende E/A in Workern in eine optionale asynchrone Laufzeitumgebung; ORM/PHQL zu Doctrine – oft die aufwändigste Migration, die separat behandelt werden muss.

Ein CRUD-Endpunkt lässt sich als einfacher Symfony-Controller implementieren. Eine Kette aus Datenerfassung, Cache und abgeleitetem Modell erfordert jedoch eine Workflow-Überlegung – und wahrscheinlich eine Neudefinition der Grenzen – bevor ein Tool ausgewählt wird.

Was man nicht tun sollte

Manche Fehler treten immer wieder auf – auch dann, wenn eine Migration nicht erforderlich ist.

Standardmäßig migrieren, weil Phalcon "veraltet" ist – während Version 5 weiterhin gepflegt wird, die SLOs gelten und das Team produktiv ist.

Ignorieren Sie das moderne Phalcon v5 - Queue, Container, Contracts, PIE - und behandeln Sie das Framework so, als ob es auf einer alten Version feststecken würde.

Frameworks wechseln, ohne Grenzen neu zu ziehen – der Spaghetti-Monolith überlebt die Namensraumänderung.

TrueAsync flächendeckend einzusetzen ignoriert dessen experimentelle Reife und erhöht den operativen Aufwand.

Die Verwechslung von I/O-Parallelität und CPU-Parallelität führt unabhängig vom Framework zu Fehlentscheidungen.

Umwandlung einer Orchestrierungsbibliothek in ein Framework – eine systematische Pipeline für jedes Feature ersetzt ein Anti-Pattern durch ein anderes.

Wir präsentieren TrueAsync als bereit für den universellen Produktiveinsatz – im Jahr 2026 gilt es, diesen Weg zu gestalten und zu testen.

Die Einführung von Async vor einem expliziten Workflow verbirgt die Orchestrierungsschulden hinter einer Ausführungsschicht.

Realistische Risiken

Fazit – über den Rahmen hinaus: explizite Orchestrierung

Phalcon war nie ein Fehler. Für leseintensive Plattformen war die Optimierung des Frameworks in C eine schlüssige Antwort – und ist weiterhin vertretbar, solange der MVC-Ansatz die dominierende Einschränkung darstellt.

Symfony ist nicht automatisch besser. Es geht um eine andere Art der Optimierung: Struktur, Ökosystem, organisatorische Wartbarkeit. Das ist relevant, wenn diese Einschränkungen die Kosten des nativen Frameworks überwiegen.

TrueAsync ist nicht automatisch die Zukunft. Es handelt sich um eine experimentelle Laufzeitoptimierung – relevant für bestimmte E/A-Profile, unabhängig von der Framework-Wahl, keine Voraussetzung für die Modernisierung.

Phalcon, Symfony und TrueAsync platzieren native – oder strukturierte oder asynchrone – Funktionen auf unterschiedlichen Ebenen des Stacks. Doch architektonische Kompetenz im Jahr 2026 endet hier nicht.

Die Branche hat jahrelang Frameworks optimiert. Die nächste Herausforderung für komplexe Systeme liegt nicht nur in der Framework-Performance, sondern auch in der expliziten Orchestrierung, klar definierten Domänengrenzen und kontextsensitiven Ausführungsstrategien. Die native Laufzeitumgebung dient als Implementierungshebel. Orchestrierung ist eine architektonische Entscheidung.

Bei Darkwood entwickeln wir Flow, weil uns ausgereifte Systeme eines gelehrt haben: Sobald Workflows über den Anfrage-Antwort-Zyklus hinausgehen, benötigen sie einen architektonischen Rahmen – und die Ausführungslogik muss von der koordinierten Geschäftslogik getrennt werden. Flow verfolgt einen Ansatz, bei dem Orchestrierung zu einem grundlegenden Element wird und nicht nur eine Ansammlung von Handlern und Cronjobs darstellt.

Die Wahl des Frameworks ist weiterhin wichtig. Sie ist jedoch nur ein Teil der Gleichung. Die eigentliche Frage lautet nicht nur: „Wo befindet sich der native Code?“, sondern auch: Wo befinden sich die Workflows?, Wo verlaufen die Schnittstellen? und Wer trägt die Verantwortung für die Orchestrierung? – in einer Architektur, die zehn Jahre Bestand haben muss.

Quellen

Dieser Artikel stützt sich auf verschiedene öffentliche Quellen, persönliche Experimente und Open-Source-Arbeiten zur modernen PHP-Architektur, asynchronen Ausführung und Workflow-Orchestrierung.

Frameworks und Laufzeitumgebung

• Phalcon Framework (offizielle Website): offizielle Dokumentation, Framework-Historie und Zephir/C-Architektur.
• Symfony Framework: Referenz für das PHP-Ökosystem mit Fokus auf Wartbarkeit und Anwendungsarchitektur.
• TrueAsync-Dokumentation: Dokumentation der experimentellen asynchronen Laufzeitumgebung basierend auf ext-async.

Darkwood-Referenzen

Ein Teil der hier vorgestellten Überlegungen stammt aus Arbeiten, die bei Darkwood zur Trennung zwischen Geschäftsworkflow und Ausführungsmodell durchgeführt wurden.

• Flow – Darkwood-Orchestrierungsbibliothek: Open-Source-Implementierung von Geschäftsprozess-Pipelines mit austauschbaren Ausführungstreibern (Fiber, Amp, ReactPHP, Swoole, Parallel, TrueAsync). Experimentelle Unterstützung für TrueAsyncDriver ist als Proof of Concept zur Erforschung von Laufzeit-entkoppelter Orchestrierung verfügbar.
• Slidewire-Präsentationsquelltext: Die Folien der zu diesem Artikel gehörenden Präsentation, die mit Slidewire erstellt wurde, sind in diesem Repository öffentlich verfügbar.