Senior Backend Engineer — Platform

About the Company

Elfster is the free way for friends, families, and coworkers to organize a Secret Santa, run any gift exchange, and build wishlists everyone can actually shop from. Since 2000, more than 47 million gift givers across 50+ countries have used the platform to draw names, manage exchanges, and shop for the people they care about.What makes engineering here interesting is the shape of the traffic. Elfster is one of the most seasonal consumer platforms you will work on: a large share of the year’s activity compresses into the weeks between early November and late December, when millions of people create exchanges, draw names, post wishlist items, and get notified — often within the same few hours on the same few days. The system has to stay quiet and cost-efficient for most of the year, then absorb an order‑of‑magnitude jump in RPS on a schedule everyone can see coming. Designing for that is not a background concern here; it is the central engineering problem.We are a small, senior team. That means real ownership, short paths from idea to production, and no layers between you and the decisions that matter.

About the Role

We are hiring a Senior Backend Engineer to bring deeper platform and scalability depth to our backend group.This is a peer role alongside our existing backend engineers who already carry infrastructure scope — not a layer above them. They own services end to end, ship features, and run what they build in AWS. You will do the same. The difference is the depth you bring to the platform layer underneath all of it: the data stores, the messaging backbone, the analytics pipeline, and the capacity thinking that determines whether peak season is uneventful or not.Concretely, you will be the engineer the team leans on when the question is “will this hold in December?” — and the one who turns that answer into architecture, load models, runbooks, and instrumentation rather than a hunch. You will also make that depth transferable: design docs others can review, patterns others can reuse, and dashboards others can read at 2am.

What You’ll Do

• Design and build scalable APIs that serve a consumer platform with a highly seasonal traffic profile — owning the service contract, its performance characteristics, and its failure behavior.
• Architect for peak. Model expected RPS and concurrency for the holiday season, size and shape systems against it, and validate through load and stress testing well ahead of November — while keeping the off-season footprint efficient.
• Own the data layer as it evolves. Make deliberate choices between relational and non‑relational stores, design schemas and access patterns that scale, and evolve them safely as features grow.
• Build and scale asynchronous infrastructure. Message queues, event and bus architectures, and the decoupling that lets the platform shed load gracefully instead of failing loudly.
• Deepen our analytics platform. Work with our OLAP/warehouse layer (Amazon Redshift) so product, growth, and marketing get reliable data as the underlying models change.
• Deploy and operate services in AWS from scratch — provisioning, networking, infrastructure as code, CI/CD, and the operational scaffolding that comes with a service being real.
• Make the system observable. Meaningful metrics, structured logs, traces, SLOs, and alerts that fire on user visible problems rather than on noise.
• Take end‑to‑end ownership. From design through development, rollout, on‑call, incident response, postmortems, and the unglamorous maintenance that makes operational excellence real rather than aspirational.
• Write things down. Design docs, architecture decision records, runbooks, and API documentation that let a smallteam move fast without holding the system in one person’s head.

What We’re Looking For

• Substantial experience building backend services and scalable APIs in C#/.NET — or comparable depth in another backend ecosystem with a genuine willingness to work in ours.
• A track record of services that stayed up and stayed fast as traffic and feature scope grew.

• In‑depth working knowledge of relational databases: modeling, indexing, query performance, migrations under load, replication and read scaling.
• Practical experience with non‑relational stores, and clear judgment about when they are the right tool.
• Real experience with message queues and bus/event‑driven architectures — delivery semantics, idempotency, ordering, retries, dead‑letter handling, and backpressure.
• Hands‑on experience with an OLAP/warehouse layer; Amazon Redshift specifically is a strong plus — including how to evolve it as u