(Senior) Distributed Systems Engineer - m/f/d

Where Europe's enterprises adopt AI

Langdock is the AI platform used by more than 10,000 companies to give employees secure access to the leading AI models, to build and share agents and to automate repetitive workflows. We have grown past $40M ARR while remaining a small team, and we care deeply about operating efficiently across the entire company.

For many enterprises, Langdock is becoming the place where most of the net-new work is produced. As people and agents create more documents, analyses, decisions, and automations inside AI interfaces, the context and data behind that work accumulate within Langdock. This gives us the opportunity to earn a larger role in their technology stack by building a platform they choose to rely on.

Our ambition is to build that platform for European enterprises while preserving their control over data, model providers, and deployment environments. We have made meaningful progress at the application layer, but much of the foundation beneath it still needs to be built.

You can watch the Meet the engineering team video to get a feeling for how we work.

The role

Distributed Systems Engineers solve our most complex technical problems inside and across Langdock's shared services when existing building blocks or standard architectures are insufficient. These are problems where correctness under failure, performance, scale, security, and cost interact.

This is a project-oriented role rather than ownership of one permanent layer. You might spend a period on distributed execution, then move into storage architecture, workload isolation, or model serving as company priorities change. The constant is sustained investigation of unfamiliar systems and responsibility for turning that understanding into a production system.

Systems Engineers own the difficult mechanism and the measurable improvement it creates, whether in correctness, capability, performance, reliability, or cost. They operate what they build, while the Platform owner remains accountable for the service contract and long-term lifecycle around it.

What you might work on

The systems agenda includes:

• Distributed state and execution. Design systems that remain correct when work is concurrent, long-running, retried, resumed, or moved between processes. Define explicit invariants for ordering, idempotency, recovery, and tenant isolation.

• Storage and data systems. Improve how large volumes of customer and agent-generated data are stored, versioned, moved, and recovered while preserving consistency, data residency, and predictable performance.

• Secure compute for agents. Develop the isolation, runtime, and scheduling mechanisms behind a shared sandbox service for untrusted code. The system needs persistent filesystems, deny-by-default networking, scoped mounts, fast startup, suspension, resumption, and predictable scheduling without weakening the security boundary.

• Inference systems. Improve the serving systems beneath the Model Gateway, optimizing throughput, latency, accelerator utilization, reliability, and cost. The work is measurement driven: understand the workload, identify the actual bottleneck, and decide where changes to serving, scheduling, caching, model format, or hardware create structural advantage.

• Resource scheduling and isolation. Make CPU, memory, storage, network, and accelerator capacity explicit so one workload cannot degrade another. Improve placement, admission control, backpressure, autoscaling, and recovery across deployment environments.

• Billing and usage metering. Build the concurrent metering mechanism behind the billing capability, accounting for heterogeneous units such as model tokens and sandbox compute time. It must stay correct when many workloads report concurrently, events arrive late or more than once, and long-running jobs reserve capacity before their final usage is known. This involves idempotent ingestion, atomic reservations, reconciliation, and auditable records.

You will start with one focused problem based on your experience and the team's priorities. The expectation is not broad activity across every domain; it is a substantial improvement in the capability, performance, reliability, or economics of the system you take on.

Tech stack

• Go and TypeScript in one Bazel monorepo, with implementation choices driven by the system

• Linux, containers, microVMs, filesystems, and networking

• Protobuf and gRPC for service contracts

• Kubernetes across GCP, AWS, Azure, and on-premises deployments

• Terraform and Terragrunt for infrastructure orchestration

• PostgreSQL and Redis where durable metadata or coordination requires them

• Open-source model serving and accelerator infrastructure

You do not need prior experience with every item. You do need enough systems depth to enter an unfamiliar part of the stack, understand its behavior, and make consequential changes safely.

How we work

• We operate with high trust and autonomy in squads of 3 to 4 engineers. A squad owns its roadmap, prioritization, technical decisions, and operation in production. Engineers are expected to find the context they need, ask for input when it improves the outcome, and move work forward without waiting for every next step to be assigned.

• We align asynchronously before scheduling a meeting. Product requirement documents (PRDs) define the user problem, intended outcome, and constraints. Design documents make architectural boundaries, tradeoffs, failure modes, migrations, and rollouts explicit. People read and challenge the thinking asynchronously; once the context is shared, a short in-office discussion or whiteboard session usually resolves the remaining questions quickly.

• We optimize for leverage. Engineers choose the AI tools that work for them, supported by clear ticket context, focused branches, automated tests, and AI review before human review. We also invest in observability, migration tooling, automated recovery, and runbooks so recurring product maintenance does not depend on someone remembering a manual step.

• The engineer who ships a change owns it in production. If something breaks, you lead the fix.

What we are looking for

• You have owned technically difficult production systems in areas such as distributed systems, databases, runtimes, inference, networking, or storage. You operate what you build and remain responsible for it after deployment.

• You reason from first principles, form testable hypotheses, and use measurement to understand unfamiliar behavior. You investigate beyond the first working solution until you understand the underlying mechanism.

• Given an underspecified problem, you identify the most important invariant, decide where depth will change the outcome, and defend what you deliberately leave out.

• You reason precisely about concurrency, isolation, ordering, data loss, and failure, while finding pragmatic ways to improve performance, reliability, or cost without unnecessary complexity.

• You use AI tools as leverage while verifying their output and retaining ownership of the result. You communicate complex systems clearly, expose uncertainty, and work constructively with others.

This is an experienced individual-contributor role. You should be able to independently investigate an unfamiliar problem, design a solution, ship it, and operate it in production. We generally expect this judgment to come from at least three to six six of full-time experience working on production systems.

Working here

This is an in-office role at Greifswalder Strasse 212 in Berlin. We work together in person because it helps us build trust, develop shared context, and make decisions quickly.

Most engineers start around 8:30. We usually eat lunch together, and dinner is available for people who stay later. Running and gym are part of the routine for many of us.