Atmora Tech

Engineering

Correct under load,
not merely fast

Backend failures are rarely dramatic. They look like a duplicated payment, a stock count drifting by four units a week, or a report that disagrees with the ledger, so we engineer for correctness first and latency second.

Overview

Services that keep the numbers right when the queue is deep and a dependency is down.

Correctness comes from boring decisions taken early: transaction boundaries drawn to match business operations, idempotency keys on anything a client might retry, and one unambiguous rule about which store owns which fact. Nearly every data integrity incident we are called in to fix traces back to one of those three.

Performance work follows measurement rather than instinct. We instrument first, then attack the actual latency distribution, which turns out to be a missing index, an N+1 query hiding behind an ORM, or a synchronous call to a third-party service sitting inside a request path that should always have been a queued job.

Operability is part of the build, not a phase bolted on after it. Structured logs with correlation identifiers, traces that cross service boundaries, alerts tied to user-visible symptoms instead of CPU graphs, and runbooks written by the people who will actually be paged at three in the morning to use them.

186 ms
p99 latency on the order write path at twice peak load
3.2x
throughput gain after moving third-party calls off the request
1.8 alerts
average out-of-hours pages per week after threshold tuning

Capabilities

What this covers

Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.

  • Data modelling and transaction design

    Schemas designed around invariants, with constraints enforced in the database rather than hoped for in application code, and transaction boundaries matching business operations instead of code convenience.

  • Asynchronous processing and queues

    Kafka and RabbitMQ pipelines with idempotent consumers, dead-letter handling and replay tooling, so a poison message costs an operator ten minutes instead of a day of manual reconciliation.

  • Performance and query optimisation

    Profiling against production-shaped data, index and query rewrites, connection pool sizing, and caching applied only where invalidation is genuinely tractable rather than everywhere it looks free.

  • Reliability engineering

    Timeouts, retries with jitter, circuit breakers and bulkheads applied per dependency, plus load-shedding rules so a degraded downstream service slows one feature rather than the entire system.

  • Observability and on-call readiness

    OpenTelemetry traces spanning service boundaries, structured logs with correlation identifiers, symptom-based alerting, and runbooks exercised in a game day before anyone is paged for real.

  • Batch, reporting and reconciliation

    Nightly jobs that are restartable and idempotent, reconciliation against source systems, and reporting served from a separate read model so analysts cannot accidentally slow order entry.

Deliverables

What you get

  • Schema with constraints, migrations and a documented ownership map
  • Idempotency and retry policy applied across externally facing writes
  • Load test results at peak and twice peak with bottlenecks named
  • OpenTelemetry instrumentation and per-service dashboards
  • Runbooks exercised in a game day, with findings folded back in
  • Capacity model tying request volume to infrastructure cost

Stack

What we build it with

  • Go
  • Java 21
  • Python
  • Node.js
  • PostgreSQL
  • Apache Kafka
  • Redis
  • RabbitMQ
  • Kubernetes
  • OpenTelemetry
  • Grafana
  • k6

Process

How the engagement runs

Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.

  1. Model the domain and its invariants

    We write down what must always hold true, such as stock never going negative or an invoice never being paid twice, then design storage so violating it is impossible.

  2. Build the critical path

    The highest-volume write path ships first with tracing and load tests attached, because it constrains almost every design decision that comes after it.

  3. Prove behaviour under failure

    Each dependency is deliberately failed, delayed and duplicated in staging. Whatever the system does under those conditions is what goes into the runbook.

  4. Load and cost calibration

    Tests at expected peak and twice peak produce a capacity model, so the growth conversation happens in figures per thousand requests rather than in instinct.

  5. Operate and tune

    Four to eight weeks of shared on-call after launch, tuning alert thresholds against real traffic and deleting the alerts nobody ever acts on.

When this is the wrong engagement

If the system serves a few hundred requests a day and the data fits comfortably in one database, dedicated backend engineering is over-provisioning, and a well-structured application framework will carry you for years.

FAQ

Questions we get asked

Can you work on a system you did not build?

Most of our backend work is inherited. We start by instrumenting rather than refactoring, because a fortnight of traces shows where the problem actually is, and it is frequently not where the team assumed. Changes then land in small reversible steps against real measurements.

How do you decide between fixing and rewriting?

Cost of change, not aesthetics. If a service has a clear boundary and its problems are query patterns and missing tests, fixing is faster and much safer. If the data model contradicts the business and every feature needs three workarounds, we replace it behind the existing interface.

Do we need Kafka?

Probably not yet. A Postgres-backed queue handles a few thousand jobs an hour with far less to operate, and plenty of systems never outgrow it. Kafka becomes the right answer with multiple independent consumers, replay requirements, or sustained volume in the tens of thousands per second.

What does handover to our operations team involve?

Shared on-call for four to eight weeks, runbooks written against incidents we have actually rehearsed, dashboards your team helped design, and a written capacity model. We step back once your engineers have resolved incidents without us, not on a date agreed in advance.

Related

More in Engineering

Start a project

Tell us what is
breaking.

We reply within one working day, and the first call is with an engineer who would actually work on it — not an account manager. If we are not the right studio for the problem, we will say so on that call.

Start a project