From developer resource to an API-driven delivery platform.

Urb-it connects e-commerce platforms to same-day delivery in the city. Over two years the assignment went from pure developer resource to close collaboration with product owners — and the business pivoted towards open APIs and checkout widgets letting external partners plug in Urb-it Delivery as a delivery option.

ClientUrb-it

PeriodAug 2016 – May 2018

RolesFullstack, DevOps

ServicePlatform engineering

01 / Problem

The delivery logic sat inside the product — not in front of the partner.

Same-day delivery in the city is a real-time problem: orders, couriers, routing and the customer promise must hold together within the same hour. Urb-it's growth, however, lay in becoming a delivery option in other people's e-commerce — and then it isn't enough that the logic works internally. It must be attachable from the outside, in checkout, by a partner without access to the team.

At the same time there was a working Azure platform with real business logic in it. Rewriting everything would have thrown away investments to win scalability. The question wasn't ”monolith or microservices” but: where must we be fast and externally exposed, and what should stand still?

ConstraintExternal partners needed proper, documented APIs — not internal endpoints.

ConstraintThe existing Azure platform was to be kept and integrated, not replaced.

ConstraintReal-time flows required a traceable event history, not just current state.

02 / Approach

Small teams, multi-cloud, one clear edge.

The work was realised in small self-organising innovation teams together with product owners: microservices in Kubernetes on AWS for what should be exposed and scale, integrated with the existing Azure platform via Azure Service Bus and AMQP.

Aug 2016Developer resource in the existing flowInto the team on the customer's terms: PHP7/Laravel and .NET Core in production, bugs and features at production pace. Trust before architecture proposals.

2017Close to product ownershipThe assignment grew into collaboration with product owners on what the platform should become — APIs and checkout widgets as business model, not technical detail.

2017Microservices in innovation teamsSmall self-organising teams built services in Python/Flask and Node-adjacent layers behind OpenResty/Nginx, containerised with Docker and run in Kubernetes on AWS.

2017 – 2018Multi-cloud integration and operationsThe AWS services were integrated with the existing Azure platform over Azure Service Bus and AMQP/RabbitMQ, with Loggly and New Relic as shared visibility.

The principle

We keep the value of earlier investments and get the scalability that externally exposed APIs demand.

03 / Architecture

Four decisions that carried the rest.

DecisionWhyConsequence

Kubernetes on AWSExternally exposed APIs needed their own scaling and release cadence, independent of the older platform.Teams could deploy their own service without coordinating the whole system.

Multi-cloud against AzureThe existing platform held working business logic that was not to be rewritten.Earlier investments were kept; the integration became a clear boundary instead of a migration.

CQRS + event sourcingReal-time delivery requires history: what happened to the order, in what sequence, and why.Traceability per event and read models tailored for the widget and partner API.

OpenResty/Nginx + Lua at the edgeOne shared edge for routing, auth and throttling in front of many small services.Partners meet a stable API contract even as the services behind it are replaced.

04 / Outcome

What actually changed.

Partner integrations— count —E-retailers that attached Urb-it Delivery via widget or API.

Cities in operation— count —Markets the platform ran same-day delivery in at the end of the assignment.

Release frequency— per week —Deploys before the microservices compared with after.

Order volume— per month —Volume passing through the new delivery flow.

Dashed boxes lack a verified number — no estimates are published.

Qualitatively the outcome is clear: Urb-it Delivery went from being its own product experience to a service others could build on, via checkout widgets and open APIs. The delivery flow became traceable event by event instead of just a current order status — the difference between guessing and being able to answer the customer.

05 / Technology

32 technologies, grouped.

Platform & operationsDockerKubernetesAWSCoreOSAlpineLinuxGit

Services & languagesPythonFlaskGunicornPHP7LaravelLumen.NET CoreLua

Edge & frontendOpenRestyNginxReactAngular

Data & messagingMongoDBPostgreSQLRedisRabbitMQAMQPAzure Service Bus

Patterns & visibilityMicroservicesCQRSEvent SourcingLogglyNew Relic

Similar assignments

← All assignments

Say hello

Got a problem worth solving?

Chat with us on WhatsApp. We reply within 48 hours.