Projects with the use of PostgreSQL

To see all projects, clear the filter

DIVID, die Einwegkunststofffonds-Plattform

Period: 07/2024 – 09/2024
Role: Software Developer
Client: Umweltbundesamt
Team size: 50
Person days: 55

The DIVID project is the digital platform of the Federal Environment Agency (UBA) for implementing the Single-Use Plastics Fund Act (EWKFondsG), through which Germany has transposed the extended producer responsibility under the EU Single-Use Plastics Directive into national law. The platform serves as the central point of contact for manufacturers, municipalities, and other eligible parties. Manufacturers of single-use plastic products are thereby involved in the costs of cleaning, collection, and disposal. The DIVID platform is developed iteratively on the basis of a modern technology stack with the guiding principles of modularity, microservices, and API-First, and enables the required digital processing of all processes from manufacturer registration and quantity reporting through to fund management and payment settlement for eligible groups.

My contributions to the project::
  • Merging functionally related microservices
  • Automated data migration of distributed databases into a common schema
  • Adaptation of the API Gateway
  • Creating the CI pipeline in Azure DevOps
  • Configuring code coverage measurement
  • Rolling out SonarQube in an IaC pipeline

cLean – Debt Collection Software

Period: 03/2020 – 04/2023
Role: Software Developer
Client: Lowell
Team size: 3
Person days: 280

With the cLean project, Lowell pursued the development of a unified debt collection software for all group companies. All claims of the DACH organization were to be processed as automatically as possible in a highly available system. A key focus was determining the possible scalability of the system at certain times when large volumes of claims had to be imported. C# was the primary programming language, but individual services were implemented in Kotlin and Go.

My contributions to the project::
  • Architecture of the microservices system
  • Defining service boundaries along business domain lines (DDD)
  • Partitioning data into aggregates
  • Concept and design of a case reference number readable by both humans and machines
  • Concept for an immutable accounting system using Event Sourcing
  • Concept and implementation of the accounting component in compliance with business rules
  • Research into settlement logic in Germany and Austria
  • Implementation of business logic
  • Realization of search queries across distributed systems (separate service using CQRS)
  • Cross-team coaching, training, and support

Central File Service

Period: 03/2020 – 06/2023
Role: Software Developer
Client: Lowell
Team size: 3
Person days: 20

Lowell processes many documents — scanned letters, legal documents, evidence of claims, and files from consumers. The goal of the project was to provide a central file service capable of storing and serving large volumes of unstructured documents in an audit-proof manner.

My contributions to the project::
  • Concept and implementation of the file service, including deciding how to store metadata
  • Design of the gRPC API
  • Upload and download functionality in the gateway to the consumer portal
  • Extension of the file service with MIME type support (required for downloads)

API-First

Period: 03/2020 – 06/2023
Role: Software Developer
Client: Lowell
Team size: 3
Person days: 120

Lowell follows an API-First strategy. The goal was to make the API available to external processes as well. To this end, a central API was provided fully automatically and used by all services. The API is subject to strict guidelines regarding design and backwards and/or forwards compatibility depending on the use case.

My contributions to the project::
  • Concept and creation of a central API-First repository based on Protobuf
  • Automated generation of release and pre-release versions for multiple programming languages to optimize development speed
  • Concept for API versioning
  • Creating APIs
  • Documentation of the API
  • Reviewing APIs with a primary focus on clarity, documentation, and breaking changes

Migration of an On-Premise Kubernetes Cluster to Azure Cloud

Period: 03/2020 – 09/2020
Role: Software Developer
Client: Lowell
Team size: 3
Person days: 120

Initially, services were operated in an on-premise Kubernetes cluster. The goal of the project was to migrate all services to Azure Cloud. Additionally, technologies and cloud services were evaluated, utility classes and templates were created for future development, and a CI/CD pipeline was established.

My contributions to the project::
  • Selection of cloud services to be used in coordination with the architect
  • Agreements on future autonomy of development teams
  • Review of existing code and resulting best practices
  • Documentation of the Transaction Outbox Pattern, idempotency, aggregates, and other useful microservice patterns
  • Utility classes for sending and receiving Protobuf business events
  • Creation of the CI part of the CI/CD pipeline
  • Evaluation and implementation of Azure Serverless
  • Setting up infrastructure using Infrastructure as Code (IaC)
  • Liveness check / readiness check for services in Kubernetes
  • Creation of cron jobs in Kubernetes
  • Creation of C# templates for building new services

Claim Data for the Consumer Portal

Period: 01/2020 – 06/2023
Role: Software Developer
Client: Lowell
Team size: 4
Person days: 50

Lowell's consumer portal is a central digital service platform for individuals with outstanding claims at the debt collection agency. Lowell consists of multiple companies that are separated both organizationally and technically. Several different debt collection software systems had to be mapped onto a single API.

My contributions to the project::
  • Onboarding new Lowell subsidiaries
  • Adaptations and extensions of the interfaces
  • Definition of the API with a focus on compatibility
  • Testing the interface locally, in the CI build, and in production (partially semi-automated)
  • Rolling out the API with zero downtime in a Kubernetes cluster
  • Analysis and resolution of production errors
  • Reduction of the number of services, as the microservices had been cut too small
  • Fixing security vulnerabilities and hardening API interfaces after penetration tests
  • Guiding the development team to sustainably avoid identified weaknesses
  • Defending the system architecture against external security auditors