Lufthansa Industry Solutions
Lufthansa Cargo and aviation engineering work across rule curation, booking APIs, partner data exchange, delivery pipelines, and observability.
IT Consultant / Senior Full-Stack Engineer at Lufthansa Industry Solutions, 2022 - 2025

- 40%
- MTTR reduction
- 4
- Lufthansa workstreams
- CI/CD
- delivery and monitoring
Work overview
A quick read on where the work sat, what made it hard, what I owned, and what changed.
Context
This work covered several Lufthansa Industry Solutions assignments, including CurationEngine, SmartBookingAPI, Cargo EDI, and Centeract. CurationEngine was the rule-driven decision layer around smartBooking / Cargo Booking API, while EDI covered operational air-cargo messaging for shipment data, eAWB/eHouseManifest, PreCheck, acknowledgements, errors, and status flows.
What was hard
The hard part was separating fast-changing cargo-booking logic from stable backend APIs while keeping partner integrations and cargo message flows reliable. The work moved between rule artifacts, API integration, EDI shipment-data messages, Kubernetes deployments, CI/CD, and incident support.
My part
I worked as a fullstack/platform-oriented engineer: writing Spring and TypeScript code, integrating APIs, supporting Drools/KIE and Maven-based rule delivery, working through architecture reviews, deploying services, tightening monitoring, and troubleshooting production-adjacent issues.
What changed
The visible result was a cleaner delivery model for booking logic and less ambiguity around production support. The clearest measured impact I can name publicly is observability work that helped reduce MTTR by 40%.
Constraints that mattered
- Several systems and teams touched the same cargo process, so interfaces and handovers had to stay understandable.
- Rule changes affected booking behavior, so versioning, promotion, rollback, and testability mattered.
- Business Central, KIE Server, Maven artifacts, containers, and API services all had to line up per environment.
- Cargo, maintenance, and EDI work all use domain-specific language; vague documentation quickly becomes expensive.
Approach
Separate rules from API code
For CurationEngine, the useful platform idea was to keep volatile cargo-booking rules in managed Drools/KIE artifacts instead of burying every condition in Java application releases.
Make deployments repeatable
Rule artifacts, runtime containers, environment properties, service credentials, and CI/CD promotion needed predictable paths across development, test, staging, and production.
Keep support close to delivery
Logs, health checks, deployment diagnostics, and handover notes were treated as part of the work because rule-runtime failures can be hard to reason about after the fact.
Key decisions
A few engineering choices that shaped the implementation and delivery path.
Present the Lufthansa work as one aviation case study
The projects shared the same pattern: airline domain constraints, enterprise delivery, platform reliability, and production support.
The case study shows the connected scope without blurring the differences between API, rules, EDI, and assistance work.
Keep booking rules versioned and deployable
A rule change can alter customer-facing booking behavior without changing the core API code.
Business logic could move through controlled build, deployment, promotion, and rollback workflows.
Treat observability as part of the release
A deployed rule container or API integration without useful runtime signals pushes work into incident calls and manual investigation.
Monitoring and troubleshooting improvements contributed to a 40% MTTR reduction.
What I did
Built
- Spring, TypeScript, and platform changes across aviation and cargo workflows.
- Delivery support around Drools/KIE rule artifacts, runtime containers, and environment-specific configuration.
- Frontend and tooling pieces for maintenance and release-management contexts.
Improved
- Rule and service release paths through CI/CD, artifact handling, documentation, and handover.
- Runtime visibility through logs, health checks, dashboards, and deployment diagnostics.
- Deployment safety around Kubernetes-based services, rule runtimes, and operational handovers.
Owned
- Technical consulting with Lufthansa teams and cross-functional stakeholders.
- Troubleshooting across rule-runtime deployments, API integration, configuration, and production support paths.
- Clear project documentation and handover notes for teams operating the systems.
Cargo booking rule-curation view
A sanitized view of how rule-managed cargo-booking decisions sat around the Booking API.
smartBooking API
Java/REST service sending offer and booking context and receiving curated booking decisions.
Curation Engine
Decisioning layer that turned shipment, route, product, and customer context into rule facts.
Cargo EDI
Operational messaging for eAWB, eHouseManifest, PreCheck, acknowledgements, errors, and status updates.
Drools / KIE Runtime
KIE Server containers executing deployed rule artifacts and returning decisions.
Delivery Platform
Business Central, Maven/KJAR artifacts, CI/CD, containers, configuration, logs, and rollback.
Learnings
- Rule engines are only useful in production when artifact versioning, deployment, and rollback are handled like normal release work.
- Cargo booking logic changes often enough that separating rules from core API code can reduce release pressure.
- The most valuable documentation explains runtime boundaries, credentials, artifact versions, and support paths.