Tendex — Investmentplattform für den Markt für digitale Assets

Das bestehende Interface der Plattform war veraltet, für Anleger unbequem und spiegelte nicht den Status eines regulierten Schweizer Fonds wider. Es war erforderlich, den visuellen Teil und die UX zu erneuern, ohne die Funktionalität zu verlieren und ohne laufende Geschäftsprozesse zu beeinträchtigen.

• Audit der bestehenden Twig-Templates und Identifikation wiederverwendbarer Komponenten.
• Entwicklung eines neuen Design-Systems: Grid, Typografie, UI-Komponenten.
• Seiten unter Verwendung von Twig sowie Integration von Twig-Komponenten für interaktive Elemente (Diagramme, Tabellen, Formulare).
• Sicherstellung von Responsivität und korrekter Darstellung auf mobilen Geräten.

Anleger oder Administratoren sollten einen Investmentplan vorzeitig beenden können, mit korrekter Neuberechnung von Rendite, Gebühren und Rückzahlung. Eine Datenunsynchronisierung bei parallelen Operationen musste vermieden werden.

• Entwurf eines Domänenmodells für die Planbeendigung unter Berücksichtigung aller Zustände (aktiv, eingefroren, in Warteschlange).
• Implementierung eines Service zur Berechnung der finalen Rendite und Gebühren.
• Auslagerung schwerer Operationen in asynchrone Tasks über RabbitMQ.
• Idempotenz der Operationen und Sperren über Redis.

Einfaches Löschen von Nutzern brach verbundene Entitäten (Investmentpläne, Transaktionen, Referrals). Es musste ein sicheres Löschen unter Wahrung der Finanzhistorie und der Regulatoranforderungen implementiert werden.

• Einführung eines Soft-Delete-Mechanismus für Nutzer unter Wahrung der Beziehungen.
• Kaskadenverarbeitung: Anonymisierung personenbezogener Daten, Erhalt der Transaktionshistorie.
• Implementierung eines Hintergrund-Tasks zur Bereinigung verbundener Entitäten über RabbitMQ.
• Logging und Audit der Löschoperationen.

Anleger benötigten die Möglichkeit, die Renditeakkumulation eines Plans vorübergehend auszusetzen, ohne ihn zu schließen — beispielsweise bei Marktinstabilität. Solche Zeiträume mussten in den Berechnungen korrekt berücksichtigt werden.

• Hinzufügen des Zustands „eingefroren" in den Lebenszyklus des Investmentplans.
• Implementierung der Logik für Pausierung der Akkumulation und korrekte Wiederaufnahme.
• Aktualisierung der Renditeberechnung unter Berücksichtigung der Einfrierung.
• Benachrichtigungen an den Anleger über den Planstatus.

Anleger wollten einen Plan im Voraus erstellen, der automatisch zu einem festgelegten Datum startet. Eine zuverlässige Aufgabenplanung war erforderlich, robust gegen Ausfälle und Neustarts von Services.

• Implementierung des verzögerten Starts über den Symfony-Scheduler + RabbitMQ Delayed Messages.
• Idempotente Verarbeitung des Starts (Schutz vor Doppelstart).
• Monitoring verzögerter Tasks und Logging.
• Benachrichtigungen an den Anleger über den Start.

Das Referral-System erforderte Flexibilität: Administratoren sollten die Zuordnung von Referrals ändern können, und Anleger die aktuelle Struktur sehen. Die bestehende Implementierung erlaubte keine Bearbeitung der Zuordnungen ohne Verlust der Akkumulationshistorie.

• Entwurf eines Modells für Referral-Beziehungen mit Versionierung.
• Implementierung eines Bearbeitungsinterfaces für Referrals für Administratoren.
• Erhalt der Akkumulationshistorie bei Änderung der Zuordnungen.
• Validierung auf zyklische Abhängigkeiten.

Wachsende Last und Anzahl an Operationen (Akkumulationen, Start/Stopp von Plänen, Benachrichtigungen) erforderten die Auslagerung schwerer Operationen aus dem synchronen HTTP-Zyklus, um Nutzeranfragen nicht zu blockieren.

• Entwurf einer Event-Queue für zentrale Domänenoperationen.
• Implementierung von Workern mit Symfony Messenger + RabbitMQ.
• Retry-Policies, Dead-Letter-Queue und Monitoring.
• Idempotenz der Handler.

Schnelle Suche über große Datenmengen (Transaktionen, Pläne, Nutzer) und Aufbau von Analytik erforderten eine spezialisierte Suchmaschine statt schwerer SQL-Abfragen.

• Konfiguration von ElasticSearch-Indizes für zentrale Entitäten.
• Implementierung der Datensynchronisation über RabbitMQ-Events.
• Suchabfragen mit Filtern und Aggregationen für die Analytik.
• Optimierung von Mappings und Reindexierung.

Hohe Frequenz von Zugriffen auf häufig genutzte Daten und Notwendigkeit des Schutzes vor Race Conditions bei parallelen Operationen erforderten zuverlässigen Cache und Sperrmechanismus.

• Einführung von Caching heißer Daten und Aggregate in Redis.
• Implementierung verteilter Sperren für kritische Operationen (Start/Beendigung von Plänen).
• Konfiguration der Cache-Invalidierung über Events.
• Monitoring von Hit/Miss und Antwortzeiten.

Ein regulierter Fonds erfordert vollständiges Audit aller Finanzoperationen: wer, wann, was und auf welcher Grundlage. Es musste ein Audit-System aufgebaut werden, das die Hauptprozesse nicht verlangsamt.

• Entwurf eines Audit-Log-Schemas mit Verknüpfung zu Nutzer, Plan und Transaktion.
• Implementierung asynchroner Audit-Schreibung über RabbitMQ.
• Tools zur Suche und zum Export von Audit-Logs für Administratoren (ElasticSearch).
• Sicherstellung der Unveränderlichkeit der Einträge.

Die Investmentplattform arbeitet im 24/7-Betrieb, und jede Verzögerung bei der Event-Verarbeitung oder ein Worker-Ausfall ist kritisch. Es war ein System zum Monitoring zentraler Metriken und für Benachrichtigungen erforderlich.

• Einrichtung der Erfassung von Metriken zu Queues (RabbitMQ), Redis, ElasticSearch und zentralen Geschäftsevents.
• Implementierung von Alerts bei Anomalien (Wachstum der DLQ, Verzögerungen, Worker-Fehler).
• Dashboards für das Team.
• Integration von Logging kritischer Operationen.