02/Technology
Areas of engineering focus.
The disciplines Aruviq builds on. These describe technical capability and direction. They are not a catalogue of commercial services, and nothing here constitutes an offer.
2.1/Disciplines
01
Network Infrastructure
The routing, transport, and connectivity layers that carry traffic between systems.
Work in this area covers how traffic is addressed, routed, and carried between endpoints: path selection, transport behaviour, congestion and loss characteristics, and the operational tooling required to observe a network rather than guess at it.
02
Distributed Systems
Services that stay correct and available across multiple machines and failure domains.
A system that runs on more than one machine has to answer questions a single process never faces: what happens during a partial failure, how state is kept consistent, and which guarantees are worth their cost. We treat those questions as design inputs rather than as problems to discover in production.
03
Systems Engineering
Working close to the operating system, where software meets real hardware limits.
Processes, memory, file descriptors, sockets, and scheduling determine how software behaves once load is real. Understanding that layer is what makes the difference between a service that degrades predictably and one that fails in ways nobody can explain afterwards.
04
Software Infrastructure
The internal layer other software depends on: interfaces, libraries, and services.
Infrastructure software is judged by how little attention it demands. We favour narrow interfaces, explicit contracts, and behaviour that is the same on the hundredth call as on the first.
05
Infrastructure Automation
Infrastructure defined as code, so environments are reproducible and reviewable.
Configuration that exists only in someone’s terminal history is a liability. Defining infrastructure as version-controlled code means changes can be reviewed before they are applied, repeated exactly, and reversed when they turn out to be wrong.
06
Performance Engineering
Measuring latency, throughput, and resource use before changing anything.
Performance work begins with measurement and ends with measurement. We are interested in distributions rather than averages, because the slowest requests are the ones users actually notice.
07
Reliability Engineering
Designing for failure explicitly, then testing that the recovery path works.
Components fail, networks partition, and dependencies time out. Reliability comes from expecting those events: health checking, redundancy, graceful degradation, bounded retries, and recovery procedures that have actually been exercised.
08
Quality Engineering
Testing, review, and maintainability treated as part of the work, not after it.
Automated tests, code review, and readable code are how a small organisation keeps a system it can still safely change in two years. We would rather write less software and understand all of it.
2.2/Practice
How the work is carried out.
The disciplines above are only useful if they are applied consistently. These practices apply to every part of our work.
- Version control and peer review for every change
- Automated testing as a condition of merging, not an afterthought
- Infrastructure defined as code and applied from a reviewed source
- Structured logging, metrics, and tracing built in from the start
- Written design notes and operational documentation kept with the code
- Least-privilege access and separation of production from development
2.3/Scope
Aruviq does not currently offer commercial services in every area listed on this page. These descriptions state where our engineering attention is directed. Any commercial engagement would be defined in a written agreement rather than inferred from this site.