MU:T

Under markusunkel.tech (MU:T), I work as a freelance software engineer, computational and data scientist based in Hamburg, Germany, with my office in the new Deutschlandhaus.

Here is my resume.

MU:T means bravery in German and controlled change in Rust, and describes my way of working: challenging assumptions, experimenting safely outside your project, and making deliberate decisions that move it in the right direction.

I solve and prevent technical problems by writing concepts, designing architectures, and implementing solutions primarily in Rust and Python. With a background in physics, computational and data science, I have spent my career turning complex, theory-heavy domains into reliable, scalable software systems. This includes founding a company with patented technology in the printing industry, building automation and data-driven products from scratch, and leading engineering teams.

Clients

I work on business-critical systems and intellectual property for my clients. For this reason, detailed project descriptions remain confidential.

Instead, I focus on generalized system patterns, problem classes, and architectural concepts drawn from client projects, which you can find further down in the section anonymized system concepts by client projects.

References

Instead of having static written testimonials I establish the following philosophy:

1. Contact one of the valued persons I worked with in Table B below.
2. You will get to know the person and me through a third party.
3. Once we start our project, it’s a WIN-WIN-WIN situation as you have only invested 5-10 minutes of your time:
   • You got direct and unfiltered information about me.
   • You met someone new; they are all very nice.
   • I donate €301 to Women in Tech e.V., you receive proof of donation in the form of an official donation receipt.

Since we do not work in the same office in person, I want to use this approach to encourage direct human interactions and point out that there are far too few women in tech prefessions.

What You Can Expect

• Clear, direct communication.
• Outcome-driven thinking: strategy first, execution second.
• Sustainable solutions designed for handover and long-term ownership; no single-point dependency.
• Radical honesty about fit, yours and mine.

Commercial Terms

How We Get Started

1. Get in touch via email contact@markusunkel.tech, phone +4917686606827 or one of my listed contact channels.
2. We get to know each other and your project in a 45-minute video call; optionally while walking around the Binnenalster in Hamburg or at your favored location.
3. Depending on the project, you receive a clear proposal with scope, timeline and next steps.
4. We start building.

Engineering Stack & Expertise

This section highlights technologies I have used extensively in production systems. These are areas where I bring hands-on experience, architectural judgment, and long-term ownership; not just familiarity.

Anonymized System Concepts by Client Projects

• Priority-Based Rate Limiting Service
• Full-Stack Growth Architecture

Priority-Based Rate Limiting Service

Challenge

The rate of notifications sent out via a customer engagement platform (CEP) to my clients customers needs to be limited. By introducing a rate limit, messages get a priority label that is required when the rate cap takes effect. Furthermore there is an API rate limit on CEP’s side that should be handled gracefully. The sum of all notifications sent out within a time range should be smaller than the rate limit for any given point in time :

We notice the time of receiving the intention that a notification should be sent out with . The priorization of a notification is noticed by such that we need to guarantee, that

such that prio 1 notifications are priotized in favor of prio 2 notifications within a tolerance of . Furthemore we want to weakly guarantee that we are following the FIFO principal for notifications with the same prio , such that

holds.

Solution Design

Messages are queued by priority. Each prio queue has a scalable consumer group of workers that are all sharing its reservation volume information in a Key-Value DB. This means that a worker with prio with a reserved volume (valid for a specified TTL) is allowed to process messages. If the sum of reserved volumes exceeds the global rate limit volume, the requesting worker with prio sets the rate-limit-hitted:p with a specified rate-limit hitted TTL, such that all requesting workers with priority cannot reserve a message volume until the restriction is resolved.

Furthermore deduplication is ensured by using message hashes as deduplication keys with a specified deduplication TTL in the key-value database.

Unprocessable (not accepted by CEP) messages are moved to a dead letter queue.

Result

The implementation handled successfully the targeted api input pressure of 2 Mio. mgs/s with a median latency of ~50ms and processed highest prio messages with a median latency of ~250ms (incl. latency of calling CEP) between and .

Full-Stack Growth Architecture

Challenge

An architecture needs to be designed for an early-stage product expected to evolve rapidly based on its first key accounts, while the teams scaled in parallel.

Planned and required components:

• Mobile and web applications
• Services: E-Commerce, CMS, Core, Authentication, Notifications
• Data-driven real-time decisions based on customer activities
• Key account specific services
• CRM and CEP (customer engagement platform)
• API for 3rd Party Services

The stack should be sustainable in terms of investment and technical debts.

Solution Design

Before diving into the solution; in my experience, there are two general options to solve these broad challenge strategically:

1. Planning a relaunch budget from the beginning on in order to fully focus on the first features (not on architecture) for the first key accounts by risking the rise of technical debts and a substantial day-2 operations overhead which will cause a relaunch which in turn can jeopardize the business model and cash flow later.
2. Invest upfront into an architecture that strategically allows to grow in terms of complexity, team sizes and changing business requirements which in turn allows the company to specifically hire new employees by having the architecture evolvement in mind.

The client has chosen the second option by relying on the following strategical and technical elements implied by the architecture drawn below in figure 4.

• Single source of truth (SSOT) / One Contract: When having changing business requirements, the most important part is the information architecture, meaning the business graph model that is reflected in the federated api schema and in the process workflows on service layer / messaging system. This allows to have a contract between the different teams to work and plan on, e.g. the marketing automation team knows which events can be used to build journeys on or a key account manager can discuss with the tech leads the implications of new features in a dialogue (no one-way communication).

• MVP: The MVP was designed to validate the business model while already establishing the architectural backbone required for growth:

  1. Establish the core information architecture by implementing the most critical services on the service layer.
  2. Expose a stable contract via a federated API to enable early mobile and web applications.
  3. Introduce event tracking and messaging to support initial KPIs, customer journeys, and the customer data pipeline that ingests raw customer data into the data warehouse and CEP / CRM.

• Growth: The growth phase extended the same architectural principles to support more teams, higher traffic and key-account-specific requirements; without restructuring the core system:

  1. Scale team onboarding by using the SSOT and One Contract as a shared planning and implementation reference.
  2. Expand analytics and activation capabilities by introducing ETL and Reverse ETL components as requirements by sales, marketing, business and UX teams matured.
  3. Grow horizontally with new key account specific features and services without leaving the architecture.

Result

As business requirements shifted significantly in the first year, the architecture absorbed change without major rework. Services were added and deprecated without destabilizing the platform, allowing engineers to stay focused on product delivery instead of repeated architectural resets.