SYSTEM Cited by 1 source

Zalando Returns Service¶

Definition¶

The Zalando Returns Service is the microservice the Zalando Returns team extracted from a monolithic legacy application as part of Zalando's "unify the user experience across platforms" effort. The service owns everything to do with customers returning articles they've bought on the Zalando Fashion Store.

Why it was extracted¶

Returns logic lived in "a soon-to-be legacy monolithic application". Risks for the extraction:

Reading old code could miss or misunderstand behaviour.
Parts of the monolith had no tests.
The application's criticality precluded downtime during cutover.

Testing alone couldn't guarantee behavioural equivalence, so the team used the parallel run pattern for the migration.

Architectural layers (as described in the cleanup)¶

The Returns microservice's parallel-run scaffolding (all removed post-migration) is described by three layer names:

Use-cases layer — the consistency-check handler that processes the async /consistency-checks POST from the monolith.
Gateway layer — a localhost gateway used to re-issue the request against the service's own real endpoint for comparison.
Entities layer — the domain model for the consistency-check logic.

Plus: a feature toggle for enabling/disabling the consistency checker, the consistency-checker route in the router, and dependency injection wiring for all of the above. Tests: unit + component. Removed at cleanup.

Migration mechanics¶

Async-consistency-checker sidecar: monolith POSTs the original request + its response to /consistency-checks; the Returns microservice returns 202 Accepted and compares asynchronously.
Metrics per operation_id: Matched / Unmatched / Failed emitted to Prometheus, dashboards in Grafana.
Cutover per endpoint via Skipper rule change.

Cleanup numbers¶

~700 lines of production code removed.
~1,300 lines of tests (unit + component) removed.

(Source: sources/2021-11-03-zalando-parallel-run-pattern-a-migration-technique-in-microservices)