Ten engineering stories — not a project list.

Evolve the platform from Spring MVC toward Spring Boot and Microservices as it scaled.

Why — As the client base and feature surface grew, moving toward Spring Boot and a microservices decomposition supported independent scaling and deployment of platform capabilities rather than a single monolithic release train.

Migrate the frontend from ExtJS toward React over the platform's lifetime.

Why — ExtJS met the platform's early enterprise-UI needs; React was adopted as the ecosystem and hiring pool shifted, without a full-stop rewrite.

Decompose the platform into 16 focused microservices rather than a smaller number of broader services.

Why — Order intake, trade matching, settlement, and notification have distinct scaling and change profiles per tenant and waste category — separating them let each evolve and scale independently.

Tradeoff accepted — More services to operate, deploy, and monitor, and more discipline required in inter-service contracts and versioning.

Use Kafka as the backbone for order-to-settlement event flow.

Why — Trade matching and settlement are inherently event-driven (an order placed, matched, and settled is a sequence of state transitions across services) — Kafka gives durable, ordered delivery and lets notification consume the same event stream without coupling to the transactional path.

Standardize on OAuth2 as the single authentication/authorization model across all client deployments.

Why — A common, well-understood standard reduces the security review burden per client and lets the platform team reason about access control once instead of per-deployment.

Own production issue triage directly rather than routing all incidents through a separate support layer.

Why — Direct ownership of triage shortened the path from an incoming production issue to a root-cause fix, since the person triaging already had the deepest context on the backend modules involved.

Model the verification lifecycle as an explicit state machine.

Why — Beckn interactions are asynchronous and multi-step (discovery → verification request → provider response → confirmation); an explicit state machine makes illegal transitions impossible and makes the adapter's behavior auditable against the RFC.

Use Ed25519 signatures for multi-tenant isolation rather than isolation by database schema/row alone.

Why — Beckn's own trust model is signature-based; aligning tenant isolation with the protocol's native cryptographic model avoids maintaining a parallel, adapter-specific isolation mechanism.

Deduplicate incoming requests by message ID.

Why — Beckn callbacks can be retried by the network; without deduplication, a retried callback could double-process a verification and corrupt state.