Local Test Data Backend API

Overview

This project implements a local HTTP backend API to ingest and retrieve test data. It intentionally avoids web frameworks and ORMs to demonstrate manual validation, explicit transaction handling, and structured logging.

• Language: Python
• Database: SQLite

---

Endpoints

POST /tests

Request body example:

{
  "test_id": "T123",
  "patient_id": "P001",
  "clinic_id": "C001",
  "test_type": "CBC",
  "result": "Normal"
}

Behavior:

• All fields are required and must be non-empty strings.
• IDs (test_id, patient_id, clinic_id) are normalized to uppercase before insertion.
• Duplicate test_id returns HTTP 409 Conflict and the transaction is rolled back.
• Success and failure events are logged in JSON format.

Response (success):

{ "message": "Test created successfully" }

GET /tests?clinic_id=

Behavior:

• Returns all tests for the specified clinic_id (case-insensitive).
• Returns an empty array if no tests exist for the clinic.
• Returns HTTP 400 if clinic_id query parameter is missing.

Response (success example):

[
  {
    "test_id": "T003",
    "patient_id": "P001",
    "clinic_id": "C001",
    "test_type": "Blood",
    "result": "Normal",
    "created_at": "2026-02-13T12:00:00Z"
  }
]

Database Schema

SQLite table: tests

Column	Type	Constraints
test_id	TEXT	PRIMARY KEY
patient_id	TEXT	NOT NULL
clinic_id	TEXT	NOT NULL
test_type	TEXT	NOT NULL
result	TEXT	NOT NULL
created_at	TEXT	NOT NULL

Transactions use explicit BEGIN / COMMIT statements; duplicate test_id rolls back and returns HTTP 409.

Structured Logging

All requests and events are logged in JSON format using logger.py. Example:

{
  "event": "request_success",
  "endpoint": "POST /tests",
  "status": 201,
  "test_id": "T123",
  "request_id": "uuid-v4"
}

Logs include request_id, endpoint, status, and failure reasons to support debugging and auditing.

Configuration

Configure via environment variables or a .env file:

DB_PATH=tests.db
HOST=127.0.0.1
PORT=8000

Defaults: HOST=127.0.0.1, PORT=8000.

Implementation Notes

• HTTP server: Python built-in http.server
• Database: raw sqlite3 with manual SQL
• Validation: manual checks and explicit transaction handling

These choices match the assessment requirement to avoid frameworks and ORMs.

Failure Modes

• Duplicate test_id → 409 Conflict
• Invalid/missing input → 400 Bad Request
• Database errors or locks → 500 Internal Server Error

Failures are logged with request_id and reasons; transactions are rolled back on errors.Used 409 conflict for duplicate records to reduce code complexity and making the clients informed of conflicts, allowing proper handling of duplicate records.

Running Locally

1. Initialize the database:

python init_db.py

2. Start the server:

python server.py

Quick API Examples

POST example (create test):

POST /tests HTTP/1.1
Host: 127.0.0.1:8000
Content-Type: application/json

{ "test_id": "T123", "patient_id": "P001", "clinic_id": "C001", "test_type": "CBC", "result": "Normal" }

GET example (list tests for clinic):

GET /tests?clinic_id=C001 HTTP/1.1
Host: 127.0.0.1:8000

Design Decisions

1. Why did you choose this framework?

• Requirements where to run locally, so using http.server, sqlite are the correct choice. It reduces the complexity and keeps the implementation simple and lightweight.

2. Where can this system fail?

• When there is database lock, system will fail.
• Duplicate test_id insert attempts.
• Missing or invalid fields in POST request
• Database connection failure
• Unexpected exceptions like invalid JSON input

3. How would you debug a data inconsistency issue?

• checking through logs to trace where the exactly it happened.
• Check through database table for duplicate, inserted records, missing rows etc.
• Comparing client input record and inserted record.

4. What would change in production vs local?

• Change the database from SQLITE to Postgres

Notes

• The project is intended for local testing and not production use.