Lenny Daume
Gespräch starten
SEOlytics GmbH Logo

SEOlytics GmbH

Hamburg

SEO-Backend-Entwicklung mit Big Data

Backend-Entwicklung für skalierbare SEO-Daten (BigData)

November 2013 - Oktober 2014
1 Jahr
Festanstellung
Produktarbeit
Hamburg

Relevanz

Warum dieser Case relevant ist

Der Case macht sichtbar, wie Problemverständnis, Verantwortung, Entscheidungen und Umsetzung in diesem Kontext zusammenkamen.

Wirkung

Skalierbare SEO-Backend-Systeme über Java/Scala, Microservices, JMS/HornetQ, mehrstufige Datenverarbeitung, Datenbanken, AWS/Docker, Google Search Console, Release-Management und Team-Coaching end-to-end von der Problemdefinition bis zum Betrieb verantwortet.

Was davon heute weiterwirkt

AI-native Systeme hängen an Datenqualität, Schnittstellen und belastbaren Backends. Dieser Case zeigt genau diese technische Grundlage.

Big Data BackendJava/ScalaMicroservicesJMS/HornetQEnd-to-End ProduktverantwortungYou Build It You Run ItRelease-Management

Belastbare Belege

Multi-DB

Datenarchitektur

MongoDB, Cassandra, Neo4j, ArangoDB und MySQL im SEO-Datenkontext eingesetzt.

AWS/Docker

Plattformarbeit

Cloud- und Container-Setup für skalierbare Backend-Entwicklung genutzt.

JMS/HornetQ

Messaging-Topologie

Queues, Topics, DLQ, Expiry- und Storage-Failover-Pfade für entkoppelte Backend-Komponenten eingesetzt.

Wo diese Erfahrung Wert schafft

  • Für Teams mit datenintensiven Produkten, bei denen Backend, Datenmodell und Delivery zusammenpassen müssen.
  • Für Organisationen, die technische Tiefe und Team-Coaching in laufender Produktentwicklung brauchen.

Case-Kontext

Überblick

SEOlytics brauchte Backend-Systeme für große SEO-Datenflüsse und schnellere technische Anpassungsfähigkeit. Über meine gesamte Zeit dort verantwortete ich Arbeit von der Problemdefinition über Produkt- und Architekturentscheidungen, Implementation, Testing und Delivery bis zum Produktionsbetrieb. Dazu gehörten Microservice-Architektur, REST/JMS-Kommunikation mit JBoss HornetQ, Daily-Rankings-Daten, Database-Reengineering und Team-Coaching.

Die technische Arbeit verband Java/Scala, Docker/AWS, Google Search Console, Search Analytics und eigene Services mit TDD, CI und Release-Management. Wichtig war nicht nur Big-Data-Verarbeitung, sondern ein Backend, das Marktänderungen schneller aufnehmen und trotzdem wartbar bleiben konnte.

Verantwortung

Aktivitäten

  • Microservice-Architektur: Neu- und Weiterentwicklung der Microservice-Landschaft
  • JMS-/HornetQ-Landschaft: Backend-Anwendungen über Queues, Topics und Request/Response-Flows entkoppelt; DLQ, Expiry- und Storage-Failover-Pfade in der Messaging-Topologie berücksichtigt
  • Kafka als Alternative für die Event-Verarbeitung evaluiert und wegen der damaligen Produktreife bewusst nicht eingeführt
  • Datenpipeline-Architektur: Bestehende DB-/HDFS-/Hive-/Solr-Batch-Verarbeitung analysiert und einen latenzärmeren JMS-/Cassandra-/Solr-Flow für Transformation, Anreicherung, historische Zustände und inkrementelle Berechnungen konzipiert
  • Search-Plattform: Apache-Solr-Cluster inklusive Sharding für skalierbare Such- und Analysepfade mitverantwortet
  • SEO-Datenmodelle: Daily Rankings, Position-Dailies und Google-Search-Console-Daten in skalierbare Verarbeitung eingebunden
  • Database-Reengineering: Performance-Arbeit, Datenmodelldesign und Big-Data-Integration
  • Technische Führung: Team-Coaching für Implementation, Architektur, Design, Testing und Dokumentation
  • Big-Data-Processing: Java/Scala, Docker/AWS und Google APIs für SEO-Datenverarbeitung
  • End-to-End-Ownership: Problemdefinition, Produktarbeit, Architektur, Umsetzung, Release und Produktionsbetrieb über die gesamte SEOlytics-Zeit verbunden

Arbeitsweise

Methodik

  • Test-Driven Development: Built-in Quality, automatisierte Tests und Mocking/Stubbing für riskante Backend-Änderungen
  • Continuous Integration: automatisierte Builds, Release-Management und Quality Gates als schnelles Feedback-System
  • Architekturentscheidungen sichtbar machen: Datenmodell, Microservice-Grenzen und Performance-Arbeit nachvollziehbar halten
  • Batch-to-Stream-Modernisierung: Zielarchitektur und Übergangspfad anhand von Business-Latenz, Datenvolumen, Persistenzbedarf und operativen Fehlerpfaden bewerten
  • Team Enablement: Coaching, Reviews und Dokumentation so einsetzen, dass Architekturwissen nicht bei Einzelpersonen hängen bleibt

Technischer Kontext

Technologie-Stack

Die Tools sind hier kein Selbstzweck. Relevant ist, welche Systemebenen im Projekt zusammengebracht wurden.

10Bereiche
53Technologien

Datenbanken & Storage

9
Google Guava CacheVarnishAWS S3MongoDBCassandraNeo4jArangoDBMySQLBig-Data-Speicher

DevOps

9
MavenDockerAWS EC2AWS GlacierApache SolrCloud-InfrastrukturGitSVNJBoss HornetQ

Tools

7
SBTJUnitTestNGSpockMockitoJiraConfluence

Backend

7
Java 8ScalaGroovyPlay FrameworkAkkaGoogle GuiceREST APIs

Frontend

2
JavaScriptJSON/XML

Sonstige

1
Solr Sharding

Daten & KI

8
NLPMachine LearningBig-Data-VerarbeitungGoogle APIs (Adwords, WebmasterTools)Google Search ConsoleSearch AnalyticsXPathData Enrichment Pipelines

CI/CD & Delivery Pipelines

3
JenkinsCI/CD PipelineNexus

Methoden & Qualität

3
Test-Driven DevelopmentProjektmanagementDokumentation

Messaging & Event Streaming

4
JMSJMS Queues & TopicsEvent-driven ArchitectureDead Letter Queues

Nächster Schritt

Wenn du ähnliche Verantwortung brauchst, können wir den nächsten sinnvollen Hebel direkt einordnen.

Schreib kurz, welche Lage, welches Ziel und welche Entscheidung gerade zusammenkommen. Ich antworte persönlich mit einer klaren Einschätzung zum möglichen Wertbeitrag.

Nächsten Hebel besprechen