“Works as Designed” is a collection of engineering notes by me, Alexey Anufriev.
I started working in software engineering while studying information technology, sometime in the mid to late 2000s. During university, I worked self-employed, building e-commerce websites and small content-driven projects. It was my first experience with commercial software, real users, and real responsibility. Of course, it was PHP and MySQL, as probably everyone did back then.
Freelancing came with its own kind of chaos. Work was irregular, urgent, and often poorly defined. There was always something new to figure out, and at that time much of it was still unfamiliar and poorly documented. I had to become T-shaped in every possible direction: configuring hosting, writing code, dealing with mail servers, managing databases, setting up backups, and so on. That period taught me more than any course: how systems fail in production and how to recover quickly, how users actually behave and what they expect, and how fragile architectural balance can be, with technical shortcuts turning into long-term constraints much faster than anticipated.
My first large-scale engineering role came around 2010 at NetCracker, in the telecommunications domain. Moving from freelance work into a large corporation was a bit of a shock. The organization was massive, the products had long histories, and the processes were complex and slow. For someone fresh out of university, it was overwhelming at first. At the same time, my academic experience helped more than I expected. Being used to quickly diving into unfamiliar topics and understanding systems that had worked the same way for years made it easier to adapt, find my place, and eventually become part of the machinery that kept large telecom systems moving forward.
Work at NetCracker was an extremely valuable experience. I learned how large systems are documented, implemented, tested, and moved through multiple stages before reaching production. Development followed a classic waterfall model, from multi-volume design documents to implementation by teams of dozens of engineers. Over time, the company started transitioning toward more agile practices, which brought a new set of lessons. Things became simpler in some ways, but never trivial. What mattered most during that period were complex development processes, very large teams, and systems built and evolved over many years.
In 2014, I moved into fintech at CRX Markets. It was a startup environment with real deadlines and real consequences, very different from what I had experienced before. I entered a new domain with almost no prior knowledge, limited experience, and a completely different pace. Development was driven by sprints, Scrum rituals, and the constant motivation to move faster.
We were building financial products under market and regulatory constraints, trying to move quickly while still bringing solid ideas to production. I worked on Java-based backend systems, web services, and integration layers built around a service bus, while also contributing to the frontend and overall user experience of the platform.
The application was fully self-hosted, which meant infrastructure became part of everyday engineering work. Keeping systems running, deploying changes, and understanding how the platform behaved outside of code was unavoidable. My earlier freelance experience and T-shaped way of working helped here more than I expected. Being used to switching contexts and taking responsibility across layers made it easier to adapt to the pace and start contributing effectively.
Overall, my time at CRX Markets reinforced an important lesson: systems do not just get redesigned. They evolve, and rarely in the direction anyone originally planned, which is still great.
Game development followed in 2017 at Chimera Entertainment and changed my perspective again. The development cycle was completely different. We would build something, try it, discard it, and repeat, sometimes many times, until one version finally clicked. The pace was fast, experimentation was constant, and complexity was expected.
I worked on the backend of an online multiplayer game, building systems around player data, progression, and live game behavior. I contributed heavily to internal tools for game designers and dashboards for management. This was my first deep dive into cloud-native systems, and clouds were everywhere. Tools, languages, services, and libraries were designed with cloud environments in mind. Operating software under unpredictable load became the norm, where any mistake could surface immediately and publicly. There was very little tolerance for downtime.
By that point, I had developed a much clearer understanding of what technology companies really are, how they operate, how different they can be from one another, and what to realistically expect from them.
Since 2018, I’ve been working at Celonis, a company that started as a startup and gradually grew into a large organization. Over the years, the scale changed dramatically. What once began in a single room evolved into multiple products, many teams, and a complex ecosystem. Technologies shifted again. Clouds remained, but now across multiple providers, with Kubernetes running countless services.
As part of a platform team, I focused on building foundational services and shared libraries that other teams and systems depended on. Over time, my focus moved increasingly toward security, both internal and external, and how it operates at industrial scale. Much of the work now is about keeping systems modern, reliable, understandable, predictable, operable, and secure over many years, even as complexity continues to grow.
Outside of work, I’m curious about how things are built at every level. I enjoy computers, both software and hardware, occasionally solder small devices, or write tiny utilities. I have a long-standing interest in retro PCs, consoles, and games overall. I spend a lot of time learning, exploring programming languages, architectures, and design approaches, mostly to better understand why systems behave the way they do.
This blog is where I write those thoughts down and try to make sense of them. Short notes and longer reflections about problems, constraints, lessons learned, and decisions, written from practice, where things often work exactly the way they were designed to.