Skip to content

The infrastructure that moves millions

Our code sells millions of train tickets a day. S3 Passenger isn't a typical SaaS product, it's the system behind real-time inventory, pricing, and reservations for some of Europe's largest rail operators.

We built it on AWS, we deploy it multiple times a day, and we give our teams the autonomy to make real technical decisions. Here you'll find out what that actually looks like.

The technical reality

We run a microservices architecture that handles everything from dynamic pricing algorithms to seat reservation conflicts across multiple train operators. Think distributed transactions, event sourcing, and real-time synchronisation at massive scale. When SNCF's high-speed network talks to regional operators, that's our code managing the complexity.

We have modules that date back to when S3 Passenger was first designed. We do not pretend everything is greenfield, but we also do not accept that ‘that is how it has always been'. Teams regularly split microservices from older modules or rewrite components in better-suited languages. 

You own what you build

A DevOps team owns its microservices end-to-end. Not "DevOps" as a buzzword - actual ownership. You write it, you deploy it, you fix it at 2am if it breaks (fortunately this is rare). You also decide how to build it. If Go works better than Java for your service, use Go. If your team wants to try a new testing framework, make the case and do it.

As a developer

You are not just writing features, you are designing microservices that handle high-concurrency workloads across real-time rail networks. You work with PostgreSQL and AWS RDS for relational data, DynamoDB for NoSQL at scale, and Liquibase to keep database migrations clean and versioned. Our teams deploy multiple times per day, so what you build today can be in production by the afternoon. Most of our developers work with Go, Kotlin, or Rust, but you often have the freedom to choose the tooling that fits your service best.

As a tester

Testing at Sqills is not just about checking boxes - it is a continuous process. You will use tools like K6, Bruno, Gatling, and Cucumber to develop automated test suites in Kotlin, Go, or Java. Simply put, you help build test frameworks that catch bugs before our customers do.

As a cloud engineer

You are the backbone of our uptime. You build and maintain the AWS infrastructure that lets our development teams deploy multiple times a day without breaking things. You work with Terraform to manage infrastructure as code, run workloads on EKS and Docker, and wire services together with EventBridge and Lambda. You track performance through New Relic, CI/CD runs through GitLab, and you're always balancing cost, performance, and security. Your goal: keeping mission-critical rail systems at 99.95% availability while giving developers the platform to move fast.