Systems architecture by Kirsty Hawker
I connect products, data and services into systems that people can understand, operate and build on.
From a public website to the services behind it, my work is about deciding where responsibilities belong, how information moves, and what happens when something goes wrong.
System explorer
Choose a system to trace its flow. Each view explains an architectural pattern from my own work, with the detail simplified for this showcase.
Present the journey and collect the user's intent.
Own business rules, protected actions and integrations.
Keep data changes behind one migration owner.
A website can evolve without taking responsibility for database migrations or exposing an integration credential in the browser.
Attach the source, business ownership and observation time.
Approve the exact candidate before it becomes a fact.
Retrieve authorised records while preserving their history.
A permissioned ledger in the existing API and database gives connected applications consistent business context without introducing a separate knowledge service.
Create a database backup and retain the previous application image.
Apply migrations explicitly, then check container and public health.
Accept a healthy release; restore the previous image if checks fail.
Application rollback and database restore are separate decisions. Automatically reversing a database could erase valid writes made after a release.
Architecture illustrations, not live monitoring. These diagrams describe selected design patterns; they do not report current service health.
Selected architecture work
Three examples of turning a connected product estate into something easier to reason about, change and support.
Connected products
Public websites and product interfaces connected to a backend that owns protected business operations.
When several interfaces use the same services, database access, credentials and business rules need an explicit home. Otherwise every interface can become another place to maintain the same logic.
Separate the customer website from the backend. Keep checkout, webhooks, uploads and admin operations in the service layer. Give database migrations one owner, and let other applications use the API.
A shared service reduces duplication but becomes an important dependency. Its contracts, health checks and release process need the same care as the product screens.
Explore the product platformPortfolio / Shared intelligence
A source-grounded knowledge layer for business facts, decisions, tasks and outcomes.
Connected products need consistent business knowledge. Every recorded fact needs its source, business context and history so that decisions can be traced and reviewed.
Use a permissioned ledger within the existing API and database. Preserve the originating business on every record. Prepare changes for exact human confirmation, keep immutable fact versions, and reject updates based on an outdated version.
Confirmation adds a deliberate step to ingestion. In return, there is a reviewable boundary between a proposed statement and a recorded fact. Shared context still needs refreshing when business conditions change.
Release engineering
A release process that treats verification and recovery as part of the architecture.
A new version can start successfully and still fail at the public boundary. Application code and database state also have different recovery requirements.
Retain the previous application image, back up before migrations and apply schema changes as an explicit deployment step. Accept the candidate only after container and public health checks pass. Keep database restoration a separate, manual decision.
More preparation makes release work deliberate. Health checks establish a baseline; they do not replace testing the actual product journey.
The way I think
My psychology background shapes how I approach technical work: what does someone need to understand, decide and recover from?
Begin with the task, the people doing it and the information they need to move forward.
Make it clear which component owns a rule, a record, a permission or a change.
Put review and confirmation where a person can meaningfully understand the effect.
Consider how the system will be checked, maintained and recovered after the first release.
Let's connect the pieces
Talk to me about the product, the people using it and the parts that need to work together.
Discuss your system See more of my work →