InterviewKata
Software architecture · Level 3: Architecture styles · Module 16a of 46

Pipeline and serverless

Two more styles complete the catalogue. The pipeline style is one of the oldest ideas in software: small steps that each do one thing, connected in a line. Serverless is one of the newest: functions that run only when an event arrives, on infrastructure you never see. They meet in practice, because many serverless systems are pipelines of functions triggered by events.

See it builtThe Architecture styles track builds these styles for one bike-share app, with code you can run: 11 Pipes and filters · 09 Serverless.

1. The idea

A car wash. Each station does one job (soak, scrub, rinse, dry), cars move one way through them, and you can add a wax station without rebuilding the others. That's a pipeline. Now imagine a car wash that only switches its machines on when a car pulls in, and charges by the second of machine time: that's serverless.

Pipeline (pipes and filters)

Work flows one way through a chain of filters, joined by pipes. Each filter is independent and usually stateless; it knows nothing about the others except the data format in its pipe. Four kinds of filter recur:

FilterJobExample
ProducerStarts the flowReads order files from a bucket
TransformerChanges the dataConverts currencies to euros
TesterChecks a condition and passes or drops dataRejects rows with no customer ID
ConsumerEnds the flowWrites to the data warehouse

Unix shell pipes, compilers (lex, parse, optimise, generate), ETL jobs, stream processors such as Apache Flink and Kafka Streams, and CI/CD pipelines all follow this style. It's usually a single deployment (one quantum) with very simple structure.

Serverless

You deploy functions (or containers) and the platform runs them on demand: it starts instances when events arrive, scales them, and stops them when idle. You pay per request and per unit of compute time, not for servers. AWS Lambda, Azure Functions, Google Cloud Run functions and Cloudflare Workers are the common platforms. As an example of the limits involved, AWS Lambda (checked October 2026) runs an invocation for at most 15 minutes, with 128 MB to 10,240 MB of memory, and a new account starts with 1,000 concurrent executions per region. It charges $0.20 per million requests plus about $0.0000167 per GB-second of compute (x86, first tier, US regions).

Serverless is a deployment and operations model as much as a style. Functions are usually small and event-driven, so a serverless system often looks like event-driven architecture (Module 14) or a pipeline, with managed queues, storage and databases around it.

How they rate

CharacteristicPipelineServerlessMicroservices
Partitioningtechnicaldomaindomain
Quanta11 to many1 to many
Cost★★★★★★★★★★★★★★★
Simplicity★★★★★★★★★★★★★★★
Scalability★★★★★★★★★★★★★★★
Elasticity★★★★★★★★★★★★★★★
Fault tolerance★★★★★★★★★★★★★★★
Evolvability★★★★★★★★★★★★★★★
Deployability★★★★★★★★★★★★★★★
Testability★★★★★★★★★★★★★★★
Performance★★★★★★★★★★★★★★★

Our qualitative ratings, 1 to 5 stars, more is better (for cost, more stars = cheaper). They compare styles in general; your context can move any of them.

2. How it works

An order-file pipeline, then one more filter

A nightly job loads 10,000 order rows into the warehouse. Watch the rows move through the filters, and what it takes to add fraud scoring.

Serverless under a burst: cold starts and the database

An image-upload API on functions goes from idle to 300 requests at once. The platform scales instantly; what's behind it may not.

3. Try it yourself

Functions or always-on containers: where's the crossover?

Compare a function's bill with two or more always-on containers (two for availability, each serving up to 200 requests a second at an assumed $60 a month). Peak traffic is taken as three times the average. Function prices are AWS Lambda's published x86 rates without the free tier; container prices are an assumption, so read the shape, not the cents.

4. Trade-offs

Pipeline: simplicity vs scale

Filters are easy to write, test and reorder. But the whole pipeline is usually one deployment: the slowest filter sets the pace, and one crash stops the line. Put queues between filters (or use a stream processor) when stages need to scale separately.

Serverless: no servers vs less control

No patching, no capacity planning, scaling to zero. In return: execution time limits, cold starts, vendor-specific triggers and configuration, and harder local testing.

Pay per use vs pay for capacity

Spiky or low traffic is far cheaper on functions. Steady, high traffic is usually cheaper on always-on containers or servers; the lab shows the crossover moving with request time.

Infinite scale vs finite dependencies

Functions scale to hundreds of instances in seconds. Databases, third-party APIs and licences don't. Scale is only as good as the slowest dependency.

5. In real projects

Pipelines hide in plain sight. Data ingestion, document processing (upload → virus scan → thumbnail → text extraction → index), and build pipelines are all pipelines. Making the stages explicit, with a clear format between them, makes them testable one stage at a time.

Protect what's behind the functions. Cap concurrency per function, put a connection pooler or proxy in front of relational databases (for example Amazon RDS Proxy or PgBouncer), and use queues so bursts become backlogs rather than outages.

Cold starts are manageable. Keep packages small, initialise lazily, choose fast-starting runtimes, and for latency-critical paths use the platform's warm-capacity features (provisioned concurrency on Lambda, minimum instances on Cloud Run).

Say it in the interview

Two-sentence answers
  • "When would you choose serverless?" For spiky or low, event-driven workloads where scaling to zero saves money and the team doesn't want to run servers. Not for steady high load, long-running work or latency-critical paths without warm capacity.
  • "How would you design this ETL job?" As a pipeline: a producer, testers that drop bad rows to a dead-letter store, transformers, and a consumer, each a separate, testable filter with a defined record format between them.
  • "What breaks first when a function-based API spikes?" Usually the database: hundreds of new function instances open hundreds of connections. A pooler and a concurrency cap fix it.
Red flags interviewers notice
  • Serverless for a steady 5,000 requests a second "because it scales".
  • Functions that open a new database connection each, with no pooler.
  • A pipeline whose filters share mutable state.

6. Remember it

Memory hook: "Stations in a line, machines on demand"A pipeline is independent stations joined one way; serverless switches the machines on only when a car arrives.
How this hook works: what "stations in a line, machines on demand" means

What the slogan means, phrase by phrase

"Stations in a line"
Filters joined by pipes, data flowing one way, each filter unaware of the others.
"machines on demand"
Serverless: instances start per event and you pay per use.

Why this picture fits: a car wash adds a wax station without touching the rest, and a pay-per-wash machine costs nothing when no cars come.

The story → the concept

The car washThe styles
Soak, scrub, rinse, dryProducer, transformers, testers, consumer
The conveyorPipes
Machines that start when a car arrivesFunctions invoked by events
The first car waits while machines warm upCold start

The trap it saves you from

Forgetting that the car park (the database) behind the wash doesn't grow when the machines do.

7. Common mistakes

Unbounded fan-out into a fixed resourceFunctions that scale to 1,000 instances in front of a database that accepts 100 connections.
Functions calling functions synchronouslyA chain of functions waiting on each other pays for every waiting second and multiplies cold starts. Use events, queues or a workflow service.
A pipeline with hidden side doorsA filter that also reads another filter's database breaks the independence that made the style simple.
Ignoring cost at steady loadThe bill that was $3 at launch can overtake servers when traffic becomes constant. Revisit the choice as load changes.

8. Design exercise (30 minutes)

  1. Draw a pipeline (10 min). For "users upload invoices as PDFs", list the filters from upload to searchable data, labelling each producer, transformer, tester or consumer.
  2. Make it serverless (10 min). Which filters become functions, which events trigger them, and where do queues go?
  3. Find the bottleneck (10 min). At 500 uploads a minute, which dependency breaks first? Add the cap, pooler or queue that protects it.

9. Self-check quiz

A pipeline filter drops rows that have no customer ID. What kind of filter is it?

Testers check a condition and pass or drop data.

A function-based API goes from idle to 300 concurrent requests. What usually fails first?

Each new instance opens connections; a relational database's limit is reached long before the platform's.

Which workload suits serverless best?

Pay-per-use and scale-to-zero win when load is uneven; long jobs hit time limits.

What is a cold start?

The platform must start the runtime and your initialisation code before handling the request.

What does the pipeline style make especially easy?

Filters only know their input and output format, so new ones slot in.

10. Go deeper

ResourceTimeWhy
Pipes and Filters pattern (Azure Architecture Center)15 minThe pattern with scaling and resilience considerations.
Lambda quotas (AWS)referenceThe limits that shape a serverless design.
Lambda pricing (AWS)referencePer-request and per-GB-second prices used in the lab.
Serverless Architectures (Mike Roberts, on martinfowler.com)45 minA thorough look at the benefits and drawbacks.