Scaling RA Delivery for more cities and countries: an infrastructure and reliability review

What we reviewed

The goal was a single, honest question: what does RA Delivery need so that adding a city, and later a country, is routine rather than risky, and so the platform stays fast and reliable as order volume climbs.

The review covered the whole product and the systems behind it, and it was deliberately stress-tested by more than one set of eyes so the conclusions are not a single opinion.

• The four apps (customer, merchant, courier, fleet) plus the web and operations surfaces.
• The infrastructure the platform runs on, how it scales, and how it stays available.
• Reliability and crash-resilience: how the system behaves when something goes wrong, and how quickly we would know.
• Readiness to launch additional Romanian cities, and later additional countries.
• The work was reviewed by a large internal automated engineering audit and, separately, by an independent council of several leading AI models (including Gemini, DeepSeek, and Cohere). All of them independently arrived at the same top priorities and the same cautions, which gives us high confidence in the plan.

Where we are today

RA Delivery today is a Romania-first pilot running in a single region, behind a global edge network for security and performance. It serves the four mobile apps and the web experience, and it accepts both cash on delivery and card payments live.

The product is functionally rich and disciplined. The pilot is genuinely stable for its current scale, and the review confirmed that the foundations we would build on are sound.

What is already strong

A large part of the review was confirming that the most important, hardest-to-get-right parts of the platform are already well built. These are the areas where mistakes would matter most, and they held up under scrutiny.

• Orders move through a strict, well-defined lifecycle, and the system refuses to let an order jump to a state that does not make sense.
• Payments are protected in layers: a multi-step approval gate before any live card processing, signed and de-duplicated payment confirmations so the same event is never applied twice, and correct reversal handling for refunds and settlements.
• Roles and permissions are decided on the server, not the device, with an extra confirmation step required for sensitive actions, so each person sees and can do only what their role allows.
• There is a complete data-deletion and erasure pipeline for honoring privacy requests properly.
• Releases go out through a gated pipeline with an automatic health check and a one-switch rollback, and backups are stored off-site and have been proven to restore.

The core engineering investment

The single most important investment ahead is about how the platform stores its working data. Today the system keeps that data in a single fast in-process model, which is exactly the right choice for an early single-region pilot: it is simple, quick, and easy to reason about.

To grow, we are evolving toward storing each kind of record (orders, payments, couriers, merchants, and so on) in its own relational database tables, with proper indexes and managed schema changes. That lets the platform run on more than one server at once, keeps data durable, and makes large datasets fast to query. We are approaching this as a careful, staged migration that runs alongside the current system until the new path is fully proven, not as a risky rewrite. This is planned evolution for scale, not a fix for a problem in today's pilot.

Reliability and observability

As the platform grows, we want to see problems before customers do, and to be confident that every scale step is safe before we take it. The reliability track is about turning that into standard practice.

• Centralized crash and error reporting across the apps, the web, and the backend, so issues surface immediately.
• Application metrics that show how the system is performing in real time.
• Shipping logs off the main host so history is preserved and searchable.
• Alerts that are actually delivered to the on-call team, not just recorded.
• Load testing ahead of each growth step, so capacity is proven in advance rather than discovered under pressure.

Real-time delivery experience

A delivery marketplace lives or dies on a smooth real-time experience, so part of the plan is dedicated to making tracking and messaging feel instant and dependable.

• Push notifications so customers, merchants, and couriers are updated the moment something changes.
• Robust background location for couriers, so live tracking keeps working reliably while they are on a delivery.
• Smoother behavior on poor or intermittent mobile networks, so a weak signal does not disrupt an order.

Preparing for more cities

We want launching a new Romanian city to be a configuration and data step, not a code change. The plan introduces the building blocks to make that true.

• City service zones and per-city configuration so each city can be set up independently.
• A repeatable city-launch checklist covering serviceability, local operations, payments handling, and a staged roll-out.
• The ability to launch a new city quietly, test it, ramp it up gradually, and roll it back cleanly with no impact on existing cities.

Preparing for more countries

A second country is a bigger step than a second city, because money, tax, language, and law all change. The plan treats this as its own stage, sequenced after the foundations are in place.

• Multi-currency support so amounts are always handled and displayed in the correct currency.
• Per-country tax and electronic invoicing, including Romania's e-Factura requirements.
• Per-country legal terms, consent, and support arrangements.
• Localized phone-number and address handling for each market.
• Clear data-residency choices about where each country's data lives, with strict separation between countries.

Target architecture

All of the reviewers, internal and independent, agreed on the same destination and the same restraint about how to get there.

The path is: first a well-organized single application backed by relational database tables; then moving slower background work onto a durable job queue handled by dedicated workers; then running several interchangeable copies of the application behind a replicated database so deployments cause no downtime. Just as important is what we are deliberately not doing: we are not jumping prematurely to a complex microservices or Kubernetes setup that a small team would struggle to operate and that would not solve the actual constraint.

Roadmap

The work is grouped by the moment it needs to be ready, so that cheap high-value improvements ship first and the larger foundational work is done deliberately and in the right order.

• Now: turn on full crash and error reporting, deliver alerts to the team, and add real-time performance metrics.
• Now: make money-related writes durable before they are confirmed, and smooth the data-saving path so it never slows requests.
• Before more cities: move each kind of record into its own relational tables with indexes, add per-city configuration and zones, and stand up a durable background job queue.
• Before another country: add multi-currency, per-country tax and e-invoicing, per-country legal and support, localized formats, and strict country separation.
• Before high traffic: run several application instances behind a replicated database, enable zero-downtime rolling deployments, and add capacity checks and fraud and cash controls.

How the AI council shaped this

Rather than rely on a single review, we asked several independent AI models to examine the plan separately and challenge it.

They converged on the same number-one priority: evolve how the platform stores its data, moving to per-entity relational tables, before scaling to new geographies. They also converged on the same caution: do not over-build by reaching for premature cloud complexity or a microservices rewrite. That agreement across independent reviewers is a strong signal that the plan is sound and appropriately staged.

What this means for customers, merchants and couriers

The pilot is stable and dependable today, and nothing in this plan changes that. These investments are about preparing for growth, made carefully and in the right order.

As they land, the platform becomes faster, more reliable, easier to keep an eye on, and ready to open in new cities and eventually new countries, while the parts that already work well stay exactly as solid as they are now.