The vocabulary behind the work.
One definition per term — the same one TantraDev engineers would give in an architecture review. Each entry is grounded in a system we operate, not paraphrased from a vendor blog. Use it as a reference, a glossary for procurement teams, or a way to follow how the pieces fit together.
Patterns & Practices. 22 entries.
The architectural concepts that shape how we build — and why we reach for them.
ACID Properties
ACID — Atomicity, Consistency, Isolation, Durability — is the set of guarantees a relational transaction system commits to. Atomicity says all-or-nothing; Consistency says invariants survive; Isolation says concurrent transactions appear serial; Durability says committed writes survive crash. In TantraDev's FinTech work ACID is non-negotiable: money movement without ACID is money loss with a probability density function.
Blue-Green Deployment
Blue-green deployment runs two identical production environments side by side. The live environment (blue) serves traffic while the new version (green) is deployed and warmed in parallel. Cutover is a load-balancer flip, and rollback is the same flip in reverse. The cost is double the compute during the window; the benefit is a zero-downtime, instantly-reversible release path.
Canary Release
A canary release routes a small percentage of production traffic (1%, 5%, 25%) to a new version while the rest stays on the previous one. Metrics — error rate, latency, business KPIs — are compared between the two cohorts in real time. The rollout proceeds only if the canary stays inside its SLO. The point is to catch regressions on real traffic with bounded blast radius.
CAP Theorem
The CAP theorem (Brewer) states that a distributed datastore can guarantee at most two of: Consistency, Availability, and Partition tolerance. Since network partitions are inevitable in real systems, the practical trade-off in any production design is between consistency and availability. Saying 'we are CP' or 'we are AP' is an architectural commitment, not a slogan — it dictates retry, replication, and failover behaviour.
CI/CD
Continuous Integration / Continuous Delivery is the discipline of automatically building, testing, and shipping every code change. CI catches regressions before they merge; CD removes the manual step between merge and production. TantraDev considers a pipeline 'real' only when a clean commit can reach production without a human gate other than a deployment-window check.
CQRS
Command Query Responsibility Segregation (CQRS) splits the write model from the read model. Commands mutate state through a narrow validated path; queries read from projections optimised for the access pattern. The benefit is independently scalable reads and writes, plus the freedom to denormalise reads aggressively. The cost is two models and the synchronisation between them.
Database Partitioning
Partitioning splits a logical table into physical pieces along a chosen key — date, tenant, currency, region. Queries that filter on the partition key only touch the relevant slice; writes spread across slices instead of contending on one. PostgreSQL native partitioning (pg_partman for management) is TantraDev's default move when a single table exceeds a few hundred million rows or query latency starts climbing with table size.
Event Sourcing
Event sourcing persists every change as an immutable event in an append-only log rather than overwriting current state. Current state is derived by replaying events. The pattern shines for audit, debugging, and integration — every state change is reproducible — but it adds projection and consistency complexity. TantraDev uses it where audit-completeness or replay matter more than write simplicity.
Eventual Consistency
Eventual consistency is a relaxation of the strong-consistency guarantee: writes propagate asynchronously across replicas, and readers may briefly observe stale state, but the system converges to a single value if writes stop. The CAP-theorem trade-off is throughput and availability under partition. TantraDev uses eventual consistency knowingly — never as a side effect — and always with a documented staleness window.
Exactly-Once Semantics
Exactly-once semantics is the guarantee that a message produces its effect exactly one time despite retries, partial failures, and broker restarts. True exactly-once across a network boundary is an illusion — in practice you implement it as at-least-once delivery plus idempotent consumers keyed on a deduplication identifier. The honest framing is 'effectively once' rather than 'magically once'.
Feature Flag
A feature flag is a runtime switch that toggles a code path on or off without redeploying. The pattern decouples deployment from release — a feature can ship to production behind a flag, be tested against real traffic with selected users, and be turned on (or rolled back) by configuration change. Flags add operational surface; the discipline is to delete them within a sprint or two of full rollout.
GitOps
GitOps is operational discipline that treats a Git repository as the single source of truth for system state — application config, infrastructure, deployment manifests. A reconciliation agent (ArgoCD, Flux) continuously drives the cluster toward whatever Git says it should be. The benefit is auditable change history and a one-revert rollback; the cost is the operational maturity to keep Git authoritative.
Golden Signals
The Four Golden Signals, from Google's SRE book, are Latency, Traffic, Errors, and Saturation — the minimum set of signals to monitor on any user-facing service. They overlap with RED and USE but stay user-facing in framing: a latency spike that customers feel matters more than CPU saturation that they don't. TantraDev alert policies are golden-signal-shaped.
Horizontal Scaling
Horizontal scaling (scaling out) adds more identical instances behind a load balancer rather than making one instance bigger (vertical scaling). The constraint is whether the workload can be partitioned cleanly — shared mutable state, ordering requirements, or session affinity all push back. TantraDev's first move on a saturated single-server monolith is to find the partition key, not to upsize the box.
Idempotency
An operation is idempotent when invoking it twice with the same input produces the same effect as invoking it once. In distributed systems an idempotency key — a client-supplied unique identifier per request — lets a server safely deduplicate retries without producing two payments, two emails, or two database rows. Every TantraDev write API that crosses a network boundary takes an idempotency key.
Infrastructure as Code
Infrastructure as Code (IaC) treats infrastructure the way teams already treat application code — version-controlled, peer-reviewed, repeatably deployable. The point is not that you write code instead of clicking — it is that every change is reviewable, every environment is reproducible, and 'who changed the prod VPC last Friday' has a `git blame` answer. TantraDev ships Terraform on every cloud engagement.
Observability
Observability is the property of a system that lets you answer questions about its behaviour from its outputs alone, without shipping new code. The three signals are metrics, logs, and traces; the operational test is whether an on-call engineer can root-cause a novel incident from the existing dashboards. Observability is in the data model from week one on every TantraDev engagement, not bolted on after launch.
RED Method
RED stands for Rate, Errors, Duration — the three service-level signals every request-driven service should emit. Rate is requests per second; Errors is the fraction that fail; Duration is the latency distribution. A RED dashboard answers 'is this service healthy right now' in under five seconds. TantraDev ships a RED dashboard per service before the first cutover on every cloud engagement.
RTO & RPO
Recovery Time Objective (RTO) is how long the business can tolerate the system being down before money is at stake. Recovery Point Objective (RPO) is how much data the business can tolerate losing. The pair is the input to the disaster-recovery design — backups, replicas, failover automation, restore drills. Without an explicit RTO/RPO every architectural choice that touches recoverability is implicit and untestable.
SLO & Error Budget
A Service Level Objective is the explicit reliability target a service commits to — say, 99.9% successful requests measured over 30 days. The complement (0.1%) is the error budget: the operationally-permitted failure for the period. When the budget is healthy, the team ships features; when it is exhausted, ship velocity stops until reliability is restored. This is the contract that turns 'reliability' from a feeling into a number.
Tokenisation Vault
A tokenisation vault replaces sensitive data (card PANs, SSNs, identity numbers) with opaque tokens at the system boundary, isolating the real values inside a dedicated service in a separate VPC. The architectural benefit is not abstract security — it is PCI DSS scope reduction. Only the vault and its callers remain in audit scope, cutting the surface that has to pass a Type 1 review from 'whole platform' to 'two services'.
USE Method
USE — Utilisation, Saturation, Errors — is Brendan Gregg's framework for diagnosing resource-level health (CPU, memory, disk, network). Utilisation is the percent of time the resource was busy; Saturation is the queue depth waiting on it; Errors is the count of operations that failed. RED tells you *that* a service is unhealthy; USE tells you *which resource* is to blame.
Technologies. 25 entries.
The languages, datastores, runtimes, and platforms in TantraDev's production stack.
Amazon Web Services
AWS is Amazon's cloud platform — the most service-dense and the operational default for most TantraDev FinTech engagements. The depth (KMS, Aurora, ECS Fargate, EKS, Lambda, SQS, EventBridge, CloudFront) covers nearly every architectural choice without forcing a multi-cloud foray. We default to AWS when the client has no existing cloud preference and the latency budget allows it.
Apache Kafka
Kafka is a distributed, partitioned, replayable log used as the backbone for event-driven systems. Producers append to topics, consumers read at their own pace, and the log retains messages for a configured window — so any consumer that fails can replay history rather than lose it. TantraDev uses Kafka (or Kafka-compatible Redpanda) where ordering, durability, and replay all matter at once.
Docker
Docker packages an application and its userspace dependencies into a portable image that runs identically across developer laptops, CI runners, and production hosts. The value is reproducibility — `docker build` produces the same artefact every time, so the bug a developer sees locally is the bug an engineer can attach a debugger to in staging.
Elasticsearch
Elasticsearch is a distributed Lucene-based search engine — the de-facto choice for full-text search, log aggregation, and faceted filtering at scale. TantraDev uses Elasticsearch (or OpenSearch where licensing matters) when full-text relevance, aggregation, and near-real-time indexing all have to coexist. For pure log search the calculus is different — Loki or ClickHouse often wins on cost.
Go
Go is a statically-typed, garbage-collected systems language from Google with first-class concurrency primitives (goroutines, channels). TantraDev reaches for Go where p99 latency budgets are tight, the service handles high-fanout I/O, or the binary needs to ship statically-linked to constrained edge runtimes. The language is small enough that a new engineer is productive in a week.
Google Cloud Platform
Google Cloud Platform is Google's cloud, strongest where data and ML workloads dominate — BigQuery, Vertex AI, Dataflow, Pub/Sub, and Cloud Run all read like first-class citizens rather than late additions. TantraDev reaches for GCP when ML training cost or analytical query economics dominate the architecture decision, particularly in EdTech and consumer-data products.
Grafana
Grafana is the de-facto dashboarding layer for production telemetry — Prometheus metrics, Loki logs, Tempo traces, and a long list of other sources rendered into one queryable surface. TantraDev ships Grafana dashboards as a deliverable on every cloud engagement, with the RED and USE dashboards built before the first cutover and the alert rules wired into the client's existing PagerDuty.
GraphQL
GraphQL is a query language for APIs where the client specifies what fields it needs and the server returns exactly that shape. TantraDev uses GraphQL where the client surface is varied (web, iOS, Android, an internal admin) and the over-fetch / under-fetch tax of REST starts costing real bandwidth. We default to REST for service-to-service and GraphQL at the BFF or storefront edge.
gRPC
gRPC is a Google-designed RPC framework over HTTP/2 with Protocol Buffers as the schema and serialization layer. The contract is the .proto file, generated code lives in every client language, and bidirectional streaming is a first-class primitive. TantraDev uses gRPC service-to-service where latency budgets and schema discipline justify the tooling tax over a JSON REST contract.
Kubernetes
Kubernetes is an open-source container orchestration platform that schedules, scales, and self-heals workloads across a fleet of nodes. TantraDev runs Kubernetes (EKS, AKS, GKE) where workload heterogeneity or multi-tenancy justifies the operational tax — and explicitly recommends managed alternatives (ECS Fargate, Cloud Run) where they don't. Picking K8s for a five-service app is usually the wrong call.
Microsoft Azure
Azure is Microsoft's cloud platform, dominant in healthcare and government deployments where existing Microsoft licensing and HIPAA BAA structure tip the calculus. TantraDev uses Azure for HIPAA-residency workloads, AKS-based Kubernetes engagements, and clients with existing Microsoft enterprise agreements. Service parity with AWS is close enough that the choice is almost always organisational, not technical.
MongoDB
MongoDB is a document database — schema-flexible JSON-shaped storage with indexes, aggregation pipelines, and replica sets. TantraDev uses MongoDB where the data model is genuinely document-shaped (CMS-like content, event payloads, user-defined schemas) and the relationships are shallow. For most transactional workloads we still default to PostgreSQL with `jsonb` columns where flexibility is needed.
Next.js
Next.js is Vercel's React framework with file-based routing, server components, route-level data fetching, and edge-runnable middleware. TantraDev ships Next.js for marketing surfaces, dashboards, and customer-facing storefronts where SEO, server-rendering, and developer ergonomics need to coexist. This site itself is a Next.js App Router build.
Node.js
Node.js is the V8-based JavaScript runtime for server workloads — non-blocking I/O, single-threaded event loop, and a package ecosystem that covers nearly every adapter you would need to talk to a payment provider, a queue, or a database. TantraDev uses Node (with TypeScript) for API services where I/O dominates compute and team velocity matters as much as raw throughput.
OpenTelemetry
OpenTelemetry is the CNCF standard for collecting traces, metrics, and structured logs from production systems. It is vendor-neutral on the wire (OTLP), so the same instrumentation feeds Grafana, Datadog, Honeycomb, or CloudWatch without code change. TantraDev installs OpenTelemetry from sprint one — observability is part of the data model, not a bolt-on.
PostgreSQL
PostgreSQL is an open-source relational database with strong ACID guarantees, MVCC concurrency, and rich extension surface (PostGIS, pg_partman, logical replication). It is the default datastore on every TantraDev engagement where the workload is transactional, the data has relationships, and the team needs the option to scale via partitioning and read replicas before reaching for a specialised store.
Python
Python is TantraDev's default for data pipelines, ML inference, and back-office tooling. The library surface (Pandas, NumPy, scikit-learn, FastAPI, PyTorch) is wide enough that 'we'll prototype in Python' rarely turns into 'we have to rewrite it' — and where it does, the contract layer is small and explicit. We pair Python with strict type hints and Pydantic on the API edge.
React
React is Meta's component-driven UI library — the runtime under nearly every modern web frontend TantraDev ships. We use React with TypeScript by default, with Server Components where the platform supports them and React Native where the same product needs to ship to iOS and Android with one team. The library is a tool; the design system around it is the deliverable.
React Native
React Native compiles a single TypeScript/React codebase down to native iOS and Android. TantraDev uses it where a founding team has one product roadmap and two app-store targets — particularly EdTech and consumer apps headed to tier-2 and tier-3 Indian markets where Android dominates and bandwidth is the constraint. Native modules cover the 10% the bridge can't reach.
Redis
Redis is an in-memory key/value store with native data structures (streams, sorted sets, hashes) and sub-millisecond access latency. TantraDev uses it for caches that need invalidation, rate limiters, idempotency-key stores, feature vectors in low-latency ML scoring paths, and Redis Streams as a pragmatic alternative to Kafka where the throughput ceiling and operational footprint don't warrant a full broker.
Rust
Rust is a memory-safe systems language with zero-cost abstractions and a borrow checker that turns whole categories of production bugs into compile errors. TantraDev uses Rust selectively — for the latency-critical 10% of a system where Node or Python don't fit the budget — and intentionally avoids it where Go would serve the same need with faster team onboarding.
TensorFlow
TensorFlow is Google's ML framework, strongest for production-grade model serving (TensorFlow Serving), mobile inference (TFLite), and large-scale training pipelines. TantraDev uses TensorFlow when the model leaves the notebook — when something has to be quantised for an Android phone, served behind a latency SLO, or trained on a multi-GPU cluster. For experimentation we are equally at home in PyTorch.
Terraform
Terraform is HashiCorp's declarative infrastructure-as-code tool. You write the desired state (a VPC, an RDS cluster, an IAM role) in HCL and Terraform reconciles cloud reality to match. TantraDev writes Terraform for everything — networks, databases, secrets, monitoring — and hands the state and modules back at the end of every engagement so the runbook works without us.
TypeScript
TypeScript is JavaScript with a structural type system — Microsoft's open-source compiler that catches whole classes of refactor regressions at build time instead of in production. TantraDev writes TypeScript in strict mode on every new codebase. The discipline is not the types themselves; it is that the contract between two services or two layers becomes the documentation.
WebSocket
WebSocket is a persistent, bidirectional TCP-style connection between browser and server, upgraded from an initial HTTP handshake. TantraDev uses WebSockets for live dashboards, collaborative editing, low-latency notifications, and real-time event fan-out. At scale the operational pattern is sticky-load-balanced gateways in front of a stateless fan-out tier — the WebSocket layer carries no business logic.
Regulations & Standards. 8 entries.
The compliance regimes our regulated-industry clients build against — PCI, HIPAA, GDPR, SOC 2.
DPDP Act
The Digital Personal Data Protection Act, 2023 (DPDP) is India's national data-protection law. It introduces consent-based processing of personal data, the role of Data Fiduciary, breach notification to the Data Protection Board, and cross-border transfer restrictions to a notified list of countries. TantraDev builds DPDP-aligned consent capture and audit logging into Indian-data products by default — the law's compliance window is narrowing.
FHIR
Fast Healthcare Interoperability Resources (FHIR, pronounced 'fire') is HL7's standard for exchanging healthcare data over RESTful APIs. Each resource — Patient, Observation, Encounter, MedicationRequest — has a canonical schema and a stable URL pattern. FHIR is the interop layer for EHR integration; TantraDev defaults to FHIR R4 for new HealthTech builds and Bridge / proxy adapters where the legacy EHR speaks HL7 v2.
GDPR
The General Data Protection Regulation (GDPR) is the European Union's data-protection law. The architectural levers it imposes are consent capture, data minimisation, the right to erasure, breach notification within 72 hours, and Data Protection Impact Assessments for high-risk processing. For TantraDev's clients serving EU users, GDPR shapes data residency, processor-controller contracts (DPAs), and the audit-logging granularity around personal data.
HIPAA
The Health Insurance Portability and Accountability Act (HIPAA) governs how Protected Health Information (PHI) is stored, transmitted, and accessed in the United States. The Privacy Rule defines what counts as PHI; the Security Rule mandates administrative, physical, and technical safeguards. TantraDev's HealthTech work treats HIPAA as architecture input from sprint one — encryption posture, audit logging, BAA scope, and minimum-necessary access all shape the design.
ISO 27001
ISO/IEC 27001 is the international standard for Information Security Management Systems (ISMS). Where SOC 2 is a US audit framework, ISO 27001 is a global certification that enterprise procurement teams — particularly outside the US — treat as the baseline security signal. The standard mandates a risk-based control selection from Annex A and a documented management system that is reviewed continuously.
PCI DSS
The Payment Card Industry Data Security Standard (PCI DSS) is the security standard every entity that stores, processes, or transmits cardholder data has to meet. The current spec is PCI DSS v4.0. The architectural lever is scope reduction: any service that does not touch a PAN can be carved out of audit, and a tokenisation vault is the standard mechanism for shrinking scope from 'whole platform' to a contained set of services.
RBI Tech Guidelines
The Reserve Bank of India publishes binding technology requirements for regulated entities — Master Directions on IT governance, the Digital Lending Guidelines (2022), the Payment Aggregator/Gateway licensing framework, and the IT Outsourcing Direction. The combined regime dictates data localisation, vendor-risk posture, incident reporting timelines, and audit trails for any FinTech operating under an Indian payment or lending licence.
SOC 2
Service Organisation Control 2 (SOC 2) is an AICPA audit framework covering five Trust Service Criteria — Security (mandatory), Availability, Processing Integrity, Confidentiality, Privacy. A SOC 2 Type 1 report attests that controls are designed correctly at a point in time; Type 2 attests they have operated effectively over a 6–12 month window. TantraDev is on track for Type 1 in Q3 2026.
Industries. 4 entries.
The four verticals our work is concentrated in, with the architectural pressure each one imposes.
E-Commerce
E-commerce engineering covers the storefront, checkout, catalogue, payment, fulfilment, and post-purchase surfaces of online retail. The architectural pressure is the inverse of FinTech: latency-to-conversion is a measured business KPI, the catalogue is read-heavy with cache-friendly shapes, and the checkout has to be both fast and idempotent across retries. TantraDev's e-commerce work is usually a headless re-platforming — separating the storefront (Next.js, edge-cached) from the commerce layer.
EdTech
EdTech is the engineering of learning and assessment software, often at the intersection of consumer-grade UX and institutional procurement. The architectural pressure in TantraDev's EdTech work is tier-2/3 Indian market reality: low-end Android, intermittent bandwidth, low ARPU. The system has to be offline-first, infrastructure-cost has to be sub-dollar per active user per month, and the personalisation loop (ML adaptive difficulty) has to work without round-tripping to a model on every interaction.
FinTech
FinTech is the engineering discipline of building money-movement, lending, and financial-services software under regulatory constraint. The defining architectural pressure is that compliance — PCI DSS, RBI tech guidelines, AML monitoring, audit-trail immutability — is not a layer added late; it dictates how data flows, where services are split, and which boundary trust crosses. Latency budgets are tight (sub-200ms card-network responses), and reconciliation is a first-class system, not a script.
HealthTech
HealthTech is the engineering of clinical, administrative, and patient-facing healthcare software under HIPAA, FHIR, and (in India) DPDP constraints. Architectural pressure points are PHI handling, role-based access at the row level, immutable audit logs that survive a forensic review, and interop with legacy EHRs that often speak HL7 v2 over MLLP. The work is rarely greenfield — it is usually a careful integration around a payer or provider that cannot tolerate downtime.
Reading about a pattern is one thing. Shipping it in production is the other.
If a glossary entry above describes a system you are trying to build (or untangle), bring it to a 30-minute architecture audit. You leave with a one-page written review — what to build, what to skip, what it will cost — even if we are not the right fit.