Walk-in || Application Data Architect

Role: Application Data Architect

What you will do

• Understand business requirements and functional specifications, identify where they are ambiguous or contradictory, and resolve them with the business analysts and agency data owners before modelling.
• Produce logical data models that non-technical stakeholders can review and approve, and physical models that perform.
• Design tables, keys, constraints, indexes, views, functions and triggers in PostgreSQL, deciding deliberately what is enforced in the database and what belongs in the application.
• Model history, status lifecycles and reversible operations so that every change is auditable and no corrective action destroys evidence.
• Design role-based and row-level access so that sensitive fields are protected at the database layer.
• Write and own versioned migrations, including changes that must be applied without downtime.
• Review and tune queries using execution plans, and advise engineering teams on access patterns.
• Maintain naming standards, the data dictionary and model documentation.
• Design how the schema is exposed through APIs, so that data can be served cleanly without leaking internal identifiers.
• Define transaction and consistency boundaries: what must be atomic, and what happens when part of an operation fails.
• Design the landing structures for data arriving from legacy agency systems, including idempotency and reconciliation.
• Translate performance and availability targets into index, partitioning and query decisions.
• Work alongside the identity resolution specialist on the link, merge and audit structures.

Mandatory skills

Data modelling

• Relational design for transactional systems: normalisation to third normal form and sound judgement on when to stop.
• Natural and surrogate keys, composite keys, and the ability to explain the trade-off in a given case.
• Expressing business rules as database constraints so that an invalid row cannot be written.
• Temporal and audit modelling: effective dating, append-only history, status lifecycles rather than boolean flags, and reversible operations.
• Separate logical and physical models, with denormalisation applied only where measurement justifies it.

Data layer architecture

• API contract design from the data side: knowing what a resource looks like over the wire, and modelling so the mapping to it is clean.
• Keeping internal keys internal, so that identifiers exposed to consumers are separate from those used inside the database.
• Transaction and consistency boundaries: what belongs in one transaction, where eventual consistency is acceptable, and how partial failure is handled.
• Security at the data layer: role design, what the application connects as, where encryption sits, and how row-level security behaves with connection pooling.
• Integration patterns at a working level: idempotency keys, change data capture, watermarking and reconciliation, sufficient to model the landing structures correctly.
• Translating non-functional requirements such as latency and availability targets into concrete schema and index decisions.

Tooling and technology

• PostgreSQL 14 or later.
• Working Python: able to write and maintain migration, profiling and data-fixture scripts.
• Git, and working within a branching and code review process.
• A data modelling tool capable of producing a reviewable logical model, such as pgModeler, ERwin or equivalent.
• Comfortable on the command line: psql, pg_dump and pg_restore, and reading server logs.

Nice to have

• Experience in a regulated transactional domain: insurance, and projects for government ministries.
• Infrastructure as code, and managing database changes through a deployment pipeline.
• Master data management, record linkage or identity resolution exposure.
• Data protection and privacy-by-design experience, including retention and minimisation.
• Experience migrating from a legacy source system, including profiling and reconciliation.
• Familiarity with SQL Server as a source system.
• Python libraries used against PostgreSQL, such as psycopg, SQLAlchemy Core and Alembic.
• Containerised local development with Docker, and ephemeral databases for testing.