Platform-as-a-service product, DubaiDeveloper infrastructureUnited Arab Emirates
The Rust backend behind a production platform-as-a-service
Core backend, microservices, billing and the internal tooling that let an entire engineering team run the production stack locally — plus Go services elsewhere handling roughly one million requests a day.
Who did this workBackend engineering by our team, delivered under a previous employer in Dubai. The high-throughput Go work described below was delivered earlier for a client we are not able to name.
The result
~1M
requests per day handled by the Go services
Technologies & disciplines
- Rust
- Go
- Microservices
- REST & gRPC
- PostgreSQL
- Redis
- Kubernetes
- Terraform
- AWS
- Docker
- Grafana
- Stripe
The situation
A platform-as-a-service product with paying customers has two problems at once. The platform itself must be reliable, because other people's software runs on it — and the team building it must be able to move quickly, which is difficult when a developer cannot run the system locally and every change has to be tested against a shared environment. Add subscription billing, and correctness stops being a matter of engineering pride and starts being a matter of charging people the right amount.
What we did
Built the core backend in Rust, designing it end to end — architecture, implementation, deployment and observability — rather than handing each stage to a different owner.
Maintained the microservices behind the platform, including the service boundaries, communication patterns and failure handling between them.
Owned subscription and billing on Stripe, where the edge cases — proration, failed payments, plan changes mid-cycle — are the whole job.
Built internal tooling that let the entire team run the full microservice stack on a local machine, removing the shared-staging bottleneck from every developer's day.
Instrumented the platform with metrics and dashboards, so reliability could be discussed with data instead of impressions.
The result
- A production platform-as-a-service backend running paying customer workloads.
- Subscription and billing handled correctly through Stripe, including the failure paths that only appear at scale.
- The whole engineering team able to run the microservice stack locally, which shortened the feedback loop for every change made afterwards.
- In a separate role, Go backend services sustaining approximately one million requests per day in production, with scalable APIs, background processing, AWS infrastructure and CI/CD introduced alongside mentoring of junior engineers.
What this shows a technical buyer
A CTO evaluating an engineering partner is not asking whether we can draw a screen. They are asking whether anyone here has operated something real — where the pager goes off, the bill has to be right, and a bad deploy affects someone else’s customers.
What this means for smaller projects
Most clients do not need a platform-as-a-service. They do need the habits that come from building one: designed failure paths, observable systems, deployments that can be rolled back, and billing logic that is tested rather than hoped for. Those habits are the same at any size, and they are what separates software that runs from software that is merely finished.
Keep reading
More work
~1.3×operational efficiency after launch
Sagawa Express. A national courier's pickup requests arrived by phone and were tracked in spreadsheets. Our team designed the online booking platform and driver application that replaced both.
48,000+parking lots managed on the platform
Tokup. A reservation product covering tens of thousands of parking lots nationwide, where the design problem was density — finding one usable space quickly, on a phone, in a hurry.
5sales channels in one order queue
In-house product. A grocery business selling through five channels at once, where the real cost was not selling — it was the nightly reconciliation between a register, a spreadsheet, a phone and an online store that never quite agreed.
2portals — customer and operations — from one codebase
In-house product. A recurring-delivery business where the operational load is not the deliveries themselves but the arithmetic around them — who gets what today, who paused, who owes, and what changes when one customer skips a week.
6service lines, each with its own page
A facility-management company. Its buyers are procurement teams comparing vendors on paper, so the site has to make the single-vendor argument itself — and then make the inquiry effortless.
3practices under one custom admin
An e-commerce agency. Three distinct practices and a service catalog too large for a static site, where the requirement was that the client could restructure their own offering without a developer.
Tell us what you are trying to build.
A 30-minute call with the people who would do the work — not a sales team. We will tell you honestly whether we are the right team for it.
- On the call
- Your goals, what exists today and the first steps. No account manager in between.
- Afterwards
- A written scope and a price within days — or a straight answer that we are not the right team.
- No obligation
- Nothing is committed until a scope is signed, and anything we send you is yours to keep.
We reply to every inquiry within one business day. Prefer email? info@sparqweb.com