Technology · Tarslink Engineering
Engineered for the operational backbone.
Seven enterprise products. A common architecture. A consistent stack. Tarslink digitises the non-retail general insurance value chain end-to-end, on infrastructure designed for the workloads insurers actually run.
At a glance
The system, in brief.
7
- across the P&C value chain
React · Django · Postgres
- Docker-native deployment
Domain monoliths
- with microservices where it matters
Customer-choice
- AWS · GCP · Azure · on-prem
01 · Product Suite
Seven products. One operational backbone.
Each product is a self-contained system, deployable independently, that solves a discrete operational problem. Together they cover the full lifecycle of a non-retail P&C policy — from RFQ through servicing, claims, investigation, and analytics.
Tarslink Platform
- Commercial P&C quotation engine
- The flagship product. Digitises the RFQ-to-policy issuance journey for commercial lines — fire, marine, engineering, liability, group health. Multi-line support, configurable covers, experience-based pricing, configurable workflow engine.
- React 19 · Django 5.1 · Postgres 16 · Redis 7 · Celery
Tarslink Connect
- Policy servicing & enrolment
- Group health policy servicing platform. Workspaces for HR, broker, ops, and TPA. Two-stage endorsement approvals, SLA-tracked queries, CD account ledger, audit-trailed enrolments. The post-policy operational layer.
- React 19 · Django 5.1 · Postgres 16 · Redis 7 · JWT RBAC
ClaimAssure
- Claims management system
- Enterprise health claims platform. FNOL through pre-auth, assessment, adjudication, settlement. Multi-channel intake — portal, email, WhatsApp, walk-in. ICD-10/PCS coding, reserve management, fraud detection, provider management.
- Next.js 14 · Django 4.2 · Postgres 15 · RabbitMQ · Elasticsearch
Tarslink Watchtower
- Investigation management
- First-class workflow for claims investigation. Case assignment, field investigator tracking, regional analytics, evidence vaulting, structured reporting, direct ingestion into the claims system. Four roles — admin, manager, vendor head, field investigator.
- React 18 · Django 4.2 · Postgres 15 · Channels · Ant Design
Tarslink Insights
- Industry analytics & ETL
- Multi-tenant insurance analytics platform. Data ingestion through extraction, processing, visualisation. Pandas/Polars data pipelines, 15+ chart types, regulatory dashboards, payment gateway integration for billing.
- React 18 · Django 4.2 · Postgres · Celery Beat · Plotly · Nivo · D3
Tarslink Broking
- IRDAI-licensed broker ERP
- Single-tenant ERP for IRDAI-registered insurance brokers. Bounded-contexts architecture (DDD): IAM, consent, audit log, outbox pattern, license validator, agency, leads, quotes, proposals, policies, renewals, commission, payments, accounting, BAP returns.
- React 19 · Django 5.1 · Postgres 15 · RabbitMQ · Ed25519
Tarslink Life
- Life products platform
- Insurance product management with underwriting workflow. Health, motor, PA, group term life products. OpenAPI-driven contracts between frontend and backend, encryption at rest via django-cryptography, S3-backed object storage.
- React 19 · Django 5.1 · Postgres 16 · pgvector · Celery Beat
02 · System Architecture
A layered architecture, built for scale and isolation.
Five layers, with clean boundaries. Each layer has a single responsibility. Each product slots into the same architectural skeleton — which makes integration, deployment, and onboarding predictable.
Figure 1 · Tarslink system architecture · five layers, clean boundaries
03 · Tech Stack
Standard, current, defensible.
No esoteric choices. No abandoned frameworks. The stack is deliberately mainstream — React, Django, PostgreSQL, Docker — so that customers can hire for it, audit it, and operate it without depending on Tarslink.
Frontend
- Framework — React 18 · 19
- Build — Vite 6 · 7 (greenfield) · CRA (legacy)
- Language — TypeScript
- Styling — Tailwind CSS v4 · Radix UI · shadcn
- State — TanStack Query · Zustand
- Forms — React Hook Form · Zod validation
- Charts — Nivo · ApexCharts · Plotly · D3 · Visx
Backend
- Language — Python 3.11 · 3.12
- Framework — Django 4.2 · 5.1 · DRF
- API spec — OpenAPI 3 via drf-spectacular
- Auth — JWT (SimpleJWT) · OAuth 2 · SSO
- Async — Celery 5 + Beat (scheduling)
- Realtime — Django Channels (WebSocket)
- Workflow — django-fsm finite-state machines
Data & Storage
- Primary DB — PostgreSQL 15 · 16
- Embeddings — pgvector (RAG-ready)
- Cache / queue — Redis 7
- Event bus — RabbitMQ 3 (outbox pattern)
- Search — Elasticsearch 8
- Object store — AWS S3 · MinIO (self-host)
- Encryption — django-cryptography at rest
Infrastructure
- Container — Docker · multi-stage
- Orchestration — Docker Compose (dev) · K8s-ready
- Web server — Nginx · Gunicorn 3-worker
- CI / CD — Bitbucket Pipelines · GitHub Actions
- Hosting — AWS · GCP · Azure · on-prem
- Monitoring — Prometheus · Grafana · Sentry
- Health — Container healthchecks everywhere
Data Engineering
- Processing — Pandas · Polars · NumPy
- I/O — openpyxl · pyarrow · PyMuPDF · Tabula
- Pipelines — Celery Beat scheduled · event-driven
- Scraping — BeautifulSoup · Selenium (controlled)
- Reports — ReportLab · QRCode · exceljs · jsPDF
Intelligence Layer
- LLM API — Anthropic Claude (Opus · Haiku)
- Embeddings — Voyage AI · OpenAI · local
- ML / NLP — scikit-learn · spaCy · TensorFlow
- OCR — Tesseract (local) · AWS Textract
- RAG — pgvector + chunk → embed → retrieve
- Use cases — Document intelligence · fraud · triage
04 · Value Chain Map
Where each product lives in the policy lifecycle.
A single policy moves through multiple stakeholders, systems, and states from request to settlement. Tarslink covers each stage with a purpose-built product — integrating through REST APIs and event bus.
Figure 2 · Tarslink products across the P&C value chain · pre-policy (cyan) to post-policy (navy)
05 · Architecture Principles
What we hold constant across products.
Each product solves a different problem, but the architectural decisions are consistent. This is what makes onboarding, integration, audit, and operations predictable for a customer running multiple Tarslink products.
Domain monoliths, not microservice sprawl.
- Each product is a single Django service with clean module boundaries. Microservices are used only where genuine independence matters — premium calculation, masters, products. We don't fragment systems that belong together.
Database-per-service where it matters.
- The calculation microservices fleet uses per-service Postgres schemas with no cross-service foreign keys, communicating via REST + Redis events. The pattern is real microservices, not distributed-monolith theatre.
Outbox pattern for guaranteed delivery.
- Domain events are written to a Postgres outbox table inside the same transaction as the business write, then drained asynchronously to RabbitMQ. No lost events, no double-spend, no surprise inconsistencies between services.
Bounded contexts by design.
- The Broking Platform follows explicit DDD bounded contexts — IAM, consent, audit log, license validator, agency, leads, quotes, policies, accounting, BAP returns. Each context owns its own models and migrations; cross-context communication is explicit.
OpenAPI as the integration contract.
- Every backend exposes drf-spectacular-generated OpenAPI 3 schemas. Frontends generate typed clients from those schemas. The contract between layers is verified at build time, not in production.
Audit-trailed by default.
- Every state change in every product is recorded with actor, timestamp, before/after payload, IP, and correlation ID. Soft-deletes preserve the record. The audit log is its own first-class subsystem, not an afterthought.
Container-native, orchestrator-agnostic.
- Every product ships with a production-grade multi-stage Dockerfile, container healthchecks, and a docker-compose.yml for local development. The same image runs on Docker Compose, Kubernetes, AWS ECS, or bare Docker.
Hosting is your choice.
- Customer-hosted on AWS, GCP, Azure, or on-premise; Tarslink-hosted as managed SaaS. The same code runs in either deployment model. No vendor lock-in to any single cloud, no opinions imposed.
06 · Security & Compliance
Built to pass insurer security review.
Tarslink products are deployed inside regulated insurers. The security and compliance posture is engineered to clear the standard insurer IT security questionnaire — and to satisfy IRDAI's outsourcing and information-security guidelines for regulated entities.
JWT · SSO · OAuth
- JWT-based auth with refresh tokens via SimpleJWT. Enterprise SSO via SAML / OAuth 2 for insurer Active Directory integration. Per-role access control across every API endpoint.
In transit · At rest
- TLS 1.2+ for all network communication. Field-level encryption at rest via django-cryptography for sensitive PII. S3 server-side encryption for documents.
Tamper-evident logs
- Every action recorded with actor, IP, timestamp, before/after state, correlation ID. Soft deletes preserve history. Logs are exportable in formats required by regulator audits.
India · ASEAN
- Customer-choice deployment — AWS Mumbai, GCP Delhi, on-prem in customer data centre. Data residency satisfies IRDAI's data localisation expectations for Indian insurers.
Prometheus · Grafana · Sentry
- Metrics emitted by every service. Dashboards for SLA, error rate, queue depth, p95 latency. Sentry-integrated error tracking with PII scrubbing. Health endpoints on every container.
Point-in-time recovery
- Postgres point-in-time recovery via WAL archiving. Daily snapshot policy. RTO and RPO tuned to insurer business-continuity requirements. Restore procedures documented and tested.
Compliance posture
IRDAI Information & Cybersecurity Framework
- Mandatory for regulated insurers
IRDAI Outsourcing Guidelines
- Vendor governance & SLA
Digital Personal Data Protection Act (DPDP) 2023
- Indian privacy law
ISO/IEC 27001 Information Security Management
- International security standard
SOC 2 Type II
- Service organisation controls
OWASP ASVS Level 2
- Application security verification
07 · Integration
Plays well with existing systems.
Tarslink does not assume it is the only system in an insurer's landscape. Every product is designed to integrate with existing core systems — policy administration, claims, billing, GL — through standards-based APIs.
Inbound APIs
- REST — OpenAPI 3 + JWT
- Schemas — Versioned, drf-spectacular generated
- Auth — JWT · OAuth 2 client credentials
- Rate limits — Per-API-key throttling
Outbound events
- Webhooks — HMAC-signed, retry-with-backoff
- Topics — Policy events, claim events, endorsement events
- Format — JSON event envelope (CloudEvents-compatible)
- Delivery — At-least-once via outbox pattern
PAS / Core integration
- Direction — Bi-directional
- Modes — Real-time API · scheduled batch · file drop
- Reconciliation — Built-in mismatch detection & resolution
- Adapters — Generic REST adapter, customer-specific custom
Identity providers
- SSO — SAML 2.0 · OAuth 2.0 · OIDC
- Directory — Active Directory · Azure AD · Okta
- Provisioning — SCIM 2.0 (planned)
- MFA — TOTP · SMS · IdP-delegated
Talk to engineering
See the architecture on your terms.
Deep-dive the stack, the security posture, and the integration model with our engineering team — mapped to the core systems you already run.
Request a demo