Distributed systems postgraduate personal statement example

Personal statement example

My interest in distributed systems began with a bug I could not explain. In a second-year concurrency module I wrote a small chat server that worked perfectly on my laptop and fell apart when two friends connected from their own machines, producing messages in an order none of us had sent them in. Reading around the problem led me to Lamport's work on ordering events in a distributed system, and to the realisation that questions I had treated as engineering details were actually about what it is possible to know when there is no shared clock and no reliable messenger. That shift in framing is why I want to study the subject properly rather than picking it up piecemeal.

I have just finished a BSc in Computer Science, with my strongest marks in operating systems, computer networks and concurrent programming. My final-year project was a replicated key-value store written in Go, running on four modest virtual machines I rented for a few pounds a month. I implemented leader election and log replication following the Raft paper, deliberately choosing Raft over Paxos because I wanted to be able to reason about my own code. The implementation worked, but the more useful part of the project was the testing: I wrote a harness that killed nodes at random intervals and introduced artificial network delays, then checked whether clients could still observe a consistent sequence of writes. Several of my early runs exposed a mistake in how I handled log entries from a stale leader, which taught me that in this field correctness claims mean very little without adversarial testing. I also measured how write latency grew as I increased the replication factor, and wrote up the trade-off between durability and responsiveness in plain terms for my report.

Two other modules shaped how I think. A databases course introduced me to transactions and isolation levels, and I became interested in why serialisability is expensive and what weaker guarantees actually promise. Reading Kleppmann's Designing Data-Intensive Applications during the summer gave me a vocabulary for these trade-offs and made me want to understand the underlying theory more rigorously, particularly consensus, failure detection and the limits described by the CAP formulation. I am aware that my current knowledge is that of a capable undergraduate who has read widely rather than someone with production experience, and a master's is the sensible way to close that gap before I work on systems other people depend on.

Outside my degree I worked weekend shifts on a supermarket checkout and later in the stock room throughout my second and third years. It funded my studies and taught me things a computing degree does not: how to stay accurate when tired, how to deal calmly with people who are annoyed for reasons that have nothing to do with me, and how a rota fails when one person is missing and nobody has planned for it. I also helped run beginners' sessions for my university's coding society, where explaining recursion and version control to first-years forced me to be honest about which parts I only half understood.

I am looking for a course that combines formal treatment of consensus and consistency with substantial practical work, ideally including a dissertation where I can extend my testing interests, perhaps by comparing how different consistency models behave under partition. In the longer term I would like to work as a backend or infrastructure engineer on systems that must keep running when individual machines do not, and eventually to contribute to open-source tooling in this area.