DIVID, die Einwegkunststofffonds-Plattform
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.
- 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
Central File Service
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.
- 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)
Claim Data for the Consumer Portal
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.
- 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