// 03 — cloud applications
Built for the traffic
you will have.
Scaling problems are rarely about servers. They are about a synchronous call that should have been a queue, a query with no index, and nobody being paged when it starts to slip. We design for the second one first.
// what we do
Architecture, not
a shopping list.
We would rather run a boring, well-understood stack you can afford and staff than an exotic one that impresses on a diagram and pages someone at 3am.
-
01
Architecture and capacity design
Where the boundaries go, what is synchronous and what is not, where state lives, and what happens when each piece fails. Written down, with the trade-offs made explicit rather than assumed.
- Service boundaries
- Failure modes
- Capacity planning
-
02
Containers and orchestration
Reproducible images, sane health checks, rolling deploys and rollback that actually works. Kubernetes where the complexity earns its keep, plain containers where it does not.
- Docker
- Rolling deploys
- Rollback
-
03
Queues, workers and background jobs
Anything slow, external or retryable belongs off the request path. Idempotent workers, dead-letter queues, backoff, and visibility into what is stuck rather than a silent backlog.
- Job queues
- Retries
- Dead-letter handling
-
04
Data layer and performance
Indexing, partitioning, read replicas and connection pooling. On one production system we partition every table by tenant, which keeps per-tenant queries fast as total volume grows.
- PostgreSQL
- Partitioning
- Read replicas
- Caching
-
05
Observability and on-call
Structured logs, metrics and traces, with dashboards and alerts tied to symptoms your users would actually notice rather than to CPU graphs nobody reads.
- Structured logs
- Metrics
- Alerting
- Tracing
-
06
Cost control
A cloud bill you can read on one page, with the three biggest line items explained and the obvious waste removed. Autoscaling that scales down as reliably as it scales up.
- Right-sizing
- Autoscaling
- Bill review
// principles
Boring technology, deliberately.
Every piece of infrastructure you add is something that can break at an inconvenient hour, needs upgrading, and has to be understood by whoever is on call. That cost is real and it is recurring, so each addition has to earn its place.
In practice this means a managed relational database before a distributed one, a queue before a microservice, and a monolith split only where there is a genuine reason — an independent scaling profile, a different failure domain, or a team boundary.
It also means designing the failure path before the happy path. What happens when the payment gateway times out halfway? When the queue backs up? When a deploy has to be rolled back at peak? Systems that survive are the ones where those answers were written down in advance rather than discovered live.
// straight answers
Questions we get
every week.
Which cloud providers do you work with?
We work across AWS, Google Cloud, Azure and cost-effective providers such as Hetzner, DigitalOcean and Contabo. For many Indian businesses a well-configured VPS with proper backups genuinely outperforms a sprawling managed setup on cost and simplicity, and we will say so when that is the case.
Can you fix a system that is already falling over?
Yes. We start by measuring rather than guessing — where the time actually goes, which queries dominate, what saturates first under load. The first fixes are usually indexing, moving work off the request path, and adding caching, well before anything needs rewriting.
Do you provide ongoing operations and on-call?
Under a retainer, yes: monitoring, patching, deploys and a defined response window. On fixed-scope work we hand over dashboards, runbooks and documentation your own team can operate from.
How do you keep cloud costs down?
Right-sizing against real measured usage, autoscaling that scales down reliably, moving cold data to cheaper storage, and reviewing the bill line by line. We aim to leave you able to explain your own bill without us.
// next step
Tell us what is actually broken.
A short message is enough to start. The first scoping call is free, and you will be talking to the person who would write the code.