This post covers what changes in everyday code, the rule that generic methods can’t satisfy interfaces, and why the Go team drew that line where it did.

The shape we’ve been writing since 1.18

Take a paginated API result. The page type is generic over its items, and sooner or later you need to turn a page of database rows into a page of response objects.

type Page[T any] struct {
	Items      []T
	NextCursor string
}

// before Go 1.27: a method can't introduce R, so this has to be a function
func MapPage[T, R any](p Page[T], f func(T) R) Page[R] {
	out := Page[R]{Items: make([]R, 0, len(p.Items)), NextCursor: p.NextCursor}
	for _, item := range p.Items {
		out.Items = append(out.Items, f(item))
	}
	return out
}

It works, but two steps in a row read inside-out: MapPage(MapPage(p, toDTO), redact). The step that runs last is the first thing you read.

What changes in 1.27

The same function becomes a method. The receiver supplies T, and the method declares R right after its name:

func (p Page[T]) Map[R any](f func(T) R) Page[R] {
	out := Page[R]{Items: make([]R, 0, len(p.Items)), NextCursor: p.NextCursor}
	for _, item := range p.Items {
		out.Items = append(out.Items, f(item))
	}
	return out
}

resp := rows.Map(toDTO).Map(redact)

Type arguments are inferred from the call’s arguments, just as they are for generic functions, so .Map(toDTO) needs no brackets. The release notes put the whole change in one sentence: “a method declaration may declare its own type parameters.”

Chaining is the obvious win, but the case I expect to use more is a non-generic type with one generic method. An HTTP client that decodes JSON into whatever type you ask for has always had to be a function that takes the client as an argument. Now it can be a method:

type Client struct {
	base string
	http *http.Client
}

func (c *Client) GetJSON[T any](ctx context.Context, path string) (T, error) {
	var out T
	req, err := http.NewRequestWithContext(ctx, http.MethodGet, c.base+path, nil)
	if err != nil {
		return out, err
	}
	resp, err := c.http.Do(req)
	if err != nil {
		return out, err
	}
	defer resp.Body.Close()
	if resp.StatusCode != http.StatusOK {
		return out, fmt.Errorf("GET %s: %s", path, resp.Status)
	}
	err = json.NewDecoder(resp.Body).Decode(&out)
	return out, err
}

user, err := client.GetJSON[User](ctx, "/users/42")

Here T appears only in the result, so there’s nothing to infer it from and you write it explicitly. The standard library uses the feature too: math/rand/v2 gains a generic (*Rand).N method.

One rule from the Go blog post on generic methods is worth knowing early: a generic method has to be instantiated, explicitly or by inference, before it’s called or turned into a function value. A method expression names both sets of type arguments, so Page[User].Map[UserDTO] is an ordinary function that takes the page as its first argument.

The one thing they can’t do: satisfy an interface

This is the rule that will catch people. From the release notes: “methods of interfaces may not declare type parameters nor can interface methods be implemented by generic methods.”

The first half means you can’t write Map[R any](...) inside an interface. The second half is subtler. Suppose an interface asks for a method whose signature exactly matches one instantiation of a generic method:

type Labeler interface {
	Label(int) string
}

type Formatter struct{}

func (Formatter) Label[T any](v T) string { return fmt.Sprint(v) }

var _ Labeler = Formatter{} // does not compile: a generic method never satisfies an interface

Formatter{}.Label[int] has exactly the signature Labeler asks for, and it still doesn’t count. The blog post explains why: “Interface implementation is a property of a (possibly instantiated) type, not of any particular method.” Formatter declares the generic Label, not Label[int].

Why the line is there

It comes down to how Go compiles. A call through an interface goes through a method table: one slot per method, each pointing at code that already exists for the concrete type. A direct call such as page.Map[string](f) is easy, because the type argument is right there at the call site and the compiler generates exactly that instantiation.

A generic method called through an interface would need code for every type argument anyone might ever pass, including types from packages that haven’t been written yet. The blog post calls that “impractical with Go’s approach to instantiation.” The alternative, boxing the arguments so that every instantiation shares one implementation, would make even direct calls pay for an indirect call. So Go 1.27 ships the useful half: type parameters on methods of concrete types, and none on interface methods.

How I’ll use them

• Typed helpers on clients and stores. client.GetJSON[T], or a repository method that scans rows into a type the caller picks, now live on the type instead of next to it.
• Short transformations on my own generic types. Map on a page or a result type reads well. I’m not going to build a streams library out of it, though. A for loop is still the clearest way to filter and sum a slice.
• Interfaces stay non-generic. If something with a generic method needs a test double, the double goes behind a small interface with concrete methods, such as GetUser(ctx, id) (User, error), and the real implementation calls GetJSON[User] inside it.

Go 1.27 also generalizes function type inference to every assignment context, so a generic function can be assigned or converted to a matching function type without spelling out its type arguments. It’s a small change that removes another set of brackets.

The takeaway

Generic methods won’t change how most Go code looks, and that’s a good thing. They take a handful of awkward top-level functions and put them back on the types they belong to. Just keep the rule in mind before you design around them: a generic method is a convenience on a concrete type, never part of an interface’s contract.

trait Storage {
    async fn get(&self, key: &str) -> Option<Bytes>;
    async fn put(&self, key: &str, value: Bytes) -> Result<(), StorageError>;
}

It compiles fine. async fn in traits has been stable since Rust 1.75, at the end of 2023. Then you try to pick the backend at startup and keep it in your app state as Arc<dyn Storage>, and the compiler stops you: the trait is not dyn compatible, because method get is async.

The 1.75 stabilization deliberately left dyn out, and nearly three years later it’s still the first wall people hit with async traits. Here’s why it happens, what to use today, and what the Rust project plans to do about it.

What an async fn in a trait returns

An async fn is sugar for a function that returns impl Future. The 1.75 announcement spells it out: an async fn in a trait desugars to a method returning impl Future<Output = ...>. So get is really this:

fn get(&self, key: &str) -> impl Future<Output = Option<Bytes>>;

That impl Future is a different anonymous type in every implementation. The compiler turns each async body into a state machine that stores everything it holds across an .await. An S3-backed store holds a request in flight, a response buffer and maybe some retry state. An in-memory store holds a reference and a key. Same method, two types, two very different sizes.

Why dyn needs to know the size

When you call a method through &dyn Storage, the call goes through a vtable and the caller doesn’t know which implementation is behind it. That’s fine for a method that returns Option<Bytes>, because the return type is the same for every implementation. It’s not fine for a method that returns an opaque future. The Rust project’s goal for this feature puts it in one line: “The caller must provide storage for the returned value, but doesn’t know its size.”

The standard way out is to give the future a known size by putting it on the heap. A Pin<Box<dyn Future>> is always the same size, a data pointer and a vtable pointer, whatever future sits inside it, so it fits through a vtable. The cost is one allocation per call.

What I use today

Static dispatch first. Most of the time dyn isn’t actually needed. A generic S: Storage parameter, or impl Storage, keeps every call unboxed. When the set of backends is closed and known, an enum works too:

enum AnyStorage {
    S3(S3Store),
    Memory(MemStore),
}

impl Storage for AnyStorage {
    async fn get(&self, key: &str) -> Option<Bytes> {
        match self {
            AnyStorage::S3(s) => s.get(key).await,
            AnyStorage::Memory(m) => m.get(key).await,
        }
    }
    // put follows the same pattern
}

No boxing, no macro, and adding a backend becomes a compile error at every match that needs updating.

When I really need dyn: async-trait or dynosaur. The async-trait crate rewrites each async method to return Pin<Box<dyn Future + Send + 'async_trait>> and wraps the body in Box::pin(async move { ... }). It’s simple and it’s everywhere, but it boxes every call, static ones included, and its futures are Send unless you write #[async_trait(?Send)].

dynosaur, maintained by Santiago Pastorino and Tyler Mandry, takes the other approach. You keep native async fn in the trait and ask for a dyn-friendly companion type:

#[dynosaur::dynosaur(DynStorage = dyn(box) Storage)]
trait Storage {
    async fn get(&self, key: &str) -> Option<Bytes>;
}

Anywhere you would have written dyn Storage, you write DynStorage instead, and you build one with constructors such as DynStorage::new_box(store). Calls through DynStorage box the returned future. Static calls on the concrete type don’t.

Or by hand. Declare the method as fn get(&self, key: &str) -> Pin<Box<dyn Future<Output = Option<Bytes>> + Send + '_>>. It works, and you lose the ergonomics of async fn in every implementation.

The Send problem next to it

A second gap shows up as soon as you tokio::spawn a call. With native async fn in a trait, a generic caller can’t require the returned future to be Send, so this fails with “future cannot be sent between threads safely”:

async fn warm_cache<S: Storage + Send + Sync + 'static>(store: Arc<S>) {
    tokio::spawn(async move {
        store.get("config").await; // the future from get() might not be Send
    });
}

Today’s answer, shipped alongside 1.75, is the trait-variant crate. Put #[trait_variant::make(Storage: Send)] on a LocalStorage trait and it generates a second trait, Storage, whose futures are all Send. The longer-term fix is return type notation, which lets the caller write the bound directly, as in S::get(..): Send. RTN is implemented on nightly behind the return_type_notation feature, and its 2026 project goal says full stabilization is blocked on the next-generation trait solver and is intended for late this year.

The plan for 2026

The Rust project’s 2026 goals include “Native async fn dynamic dispatch in traits”. It’s accepted, spans 2026 and 2027, and is owned by Jack Huey and Santiago Pastorino. It comes in two phases:

1. Method-scoped dyn compatibility, about four months. Instead of rejecting a whole trait because some methods can’t be dispatched dynamically, the trait becomes dyn compatible anyway, and those methods are reachable only through a new mechanism.
2. Async through dynamic dispatch, about eight months, built on top of that.

The first concrete piece is a deliberately minimal, nightly-only helper that boxes at the call site:

async fn fetch_data(client: &dyn HttpClient, url: &str) -> Response {
    std::preview::dyn_box!(client.fetch(url)).await
}

The allocation happens only where you ask for it, and static calls don’t change at all. The roadmap calls this .box notation, but it’s explicit that no final syntax has been agreed and that the details will be settled in RFCs. Treat any syntax you see now as a sketch.

What I’d do today

• Reach for generics or an enum first. A lot of code that seems to need dyn has a closed set of implementations.
• For open-ended dyn, use dynosaur in new code so static calls stay unboxed, and async-trait where a codebase already standardizes on it.
• Don’t fear the box. One allocation per call is noise next to a network round trip. It matters in tight loops, not in a storage call.
• Watch the project goal. When native support lands, traits already written with plain async fn will have the least to change.

Until recently the tools for this were indirect: graph runtime.NumGoroutine, take a goroutine profile and look for suspicious piles of identical stacks, or catch leaks in tests with goleak. Go 1.27 adds a direct one. The goroutineleak profile, an experiment in Go 1.26 behind GOEXPERIMENT=goroutineleakprofile, is now generally available, and the experiment flag is gone.

A leak in a dozen lines

The most common shape I know is fan out, collect, and return early on the first error.

type result struct {
	resp Response
	err  error
}

func fetchAll(ctx context.Context, urls []string) ([]Response, error) {
	ch := make(chan result)
	for _, u := range urls {
		go func() {
			resp, err := fetch(ctx, u)
			ch <- result{resp, err} // blocks forever once fetchAll has returned
		}()
	}

	var out []Response
	for range urls {
		r := <-ch
		if r.err != nil {
			return nil, r.err // the remaining senders are now stuck
		}
		out = append(out, r.resp)
	}
	return out, nil
}

The channel is unbuffered, so every send waits for a receive. When one fetch fails, fetchAll returns, and every goroutine that hasn’t sent yet blocks on ch <- with nobody left to receive. The fix is one line, a buffer with room for every sender, make(chan result, len(urls)), or an errgroup with a context that cancels the rest.

How the runtime knows a goroutine can never wake up

You can’t tell a leaked goroutine from a slow one by looking at it. Both are blocked on a channel. The difference is whether anything still running could ever unblock it, and that’s a reachability question, which is exactly what the garbage collector answers all day.

The Go blog post on goroutine leak profiles defines it precisely. A goroutine is live if it isn’t blocked by a concurrency primitive, or if at least one primitive blocking it is referenced by another live goroutine. To find the rest, the runtime adapts the garbage collector’s marking phase:

1. A normal GC treats every goroutine as a root. Here, marking starts only from global variables and the goroutines that aren’t blocked.
2. When marking reaches a channel or lock that a blocked goroutine is waiting on, that goroutine becomes reachable too, and marking continues from it.
3. When nothing new gets marked, any blocked goroutine that’s still unmarked is waiting on something only other stuck goroutines can reach. It’s reported as leaked.

The leaked goroutines are then marked anyway, so their memory isn’t freed out from under them. The profile reports leaks; it doesn’t collect them.

It covers goroutines blocked on channel sends and receives, including on nil channels, on a select without a default case, and on sync.Mutex, sync.RWMutex, sync.WaitGroup and sync.Cond.

Reading the profile

If your service already registers net/http/pprof, there’s nothing to add. The profile shows up at /debug/pprof/goroutineleak next to the others:

curl http://localhost:6060/debug/pprof/goroutineleak > leak.prof
go tool pprof leak.prof

From there it works like any other pprof profile. top shows where the leaked goroutines are stuck, grouped by stack, and list fetchAll points at the exact line, which in the example above is the send. Unlike the plain goroutine profile, you don’t have to guess which of a thousand parked stacks are the bad ones: everything in it is a goroutine the runtime has decided can never be woken.

What it can’t see

A clean profile doesn’t mean there are no leaks. The blog lists three limits, and they’re worth knowing before you trust an empty result:

• Anything still reachable. If the channel or mutex a goroutine waits on can be reached from a global variable or from a goroutine that’s still running, the waiting goroutine is never reported, even if nothing will ever use that channel again. A channel parked in a package-level map is invisible to it.
• Blocking that isn’t a channel or a sync primitive. A goroutine stuck on network or file I/O, or in a system call, is never considered leaked. A conn.Read with no deadline can hang forever without appearing. Deadlines and contexts are still your job.
• Leaks that haven’t happened yet. The profile finds a leak after it occurs. To catch one before it ships, pair it with goleak and testing/synctest in tests.

There’s a cost note too. The memory overhead is negligible, but in the worst case, a long chain of goroutines each blocked on the next, detection takes O(n²) steps for one GC cycle, where n is the number of goroutines. The blog suggests tuning how often you collect it, for example every few hours, rather than scraping it continuously.

My checklist for every go statement

• Who receives what this goroutine sends, and what happens if they stop early? If there’s an early return, buffer the channel or select on ctx.Done().
• Who closes the channel this goroutine ranges over?
• Does every network call it makes have a deadline?
• Is there a goleak.VerifyNone(t) in the package’s tests?

And now one more: collect /debug/pprof/goroutineleak in staging after a load test. A goroutine count that only goes up used to mean an afternoon of reading stack dumps. Now the runtime hands you the line.

These are the four places I look.

1. Futures are bigger than they look

Tokio tasks are cheap. The Tokio tutorial says a task needs “only a single allocation and 64 bytes of memory”, and that applications can spawn thousands, even millions, of them. What those 64 bytes don’t include is the future itself, and the future lives in that same allocation.

An async fn compiles to a state machine, and every local that’s alive across an .await becomes a field of it. Futures you await are stored inline too, with their own locals, all the way down. So this innocent-looking handler costs 64 KiB per connection for its whole life, whether it’s reading or not:

async fn handle(mut socket: TcpStream) -> io::Result<()> {
    let mut buf = [0u8; 64 * 1024]; // lives in the future, across every .await below
    loop {
        let n = socket.read(&mut buf).await?;
        if n == 0 {
            return Ok(());
        }
        socket.write_all(&buf[..n]).await?;
    }
}

A hundred thousand idle connections is over 6 GiB of buffers, and nothing is leaking.

Finding these is easy once you know to look:

• std::mem::size_of_val(&fut) on a future, before you spawn it, gives its size. A small test that checks it catches regressions in the futures you spawn per connection or per message.
• Clippy’s large_futures lint flags futures over a size threshold, 16 KiB by default. It’s in the pedantic group, so you have to turn it on.
• tokio-console has large-future and auto-boxed-future warnings, the second for futures the runtime boxed because they were large.

The fixes: keep big buffers in a Vec or BytesMut sized to what you actually need, or Box::pin a large inner future so it gets its own allocation while it runs instead of living inside every outer future. Large futures can also overflow the stack before they’re ever spawned, which is the other reason Clippy warns about them.

2. Queues without backpressure

The second place is any queue that can grow without limit. Tokio’s unbounded_channel docs are blunt about it: it’s a channel “without backpressure”, and if the receiver falls behind, messages are “arbitrarily buffered”. The only real limit is system memory, and when that runs out the process is aborted.

A bounded channel turns that failure into a slowdown. With mpsc::channel(64), send().await waits while the queue is full, so the producer runs at the consumer’s pace and memory stays flat.

let (tx, mut rx) = tokio::sync::mpsc::channel::<Event>(1024);

// producer: waits here instead of piling up events while the consumer is behind
tx.send(event).await?;

The same thinking applies to anything that buffers: a Vec you push to in a loop, a stream with buffer_unordered, a cache without eviction. For broadcast channels, remember that the capacity is rounded up to the next power of two and allocated up front, and that a receiver which falls too far behind gets a Lagged error and skips the oldest messages rather than growing the buffer.

3. The allocator is holding it, not you

This one looks exactly like a leak. Traffic spikes, memory climbs, traffic drops, and resident memory (RSS) stays high for hours, while a heap profile shows live allocations back at their baseline. Nothing is leaking. The allocator is keeping freed memory instead of returning it to the operating system.

On Linux, Rust uses the system allocator by default, which is usually glibc’s malloc. glibc gives threads separate arenas to reduce contention, and the arena limit is usually a multiple of the number of CPUs. Each arena is its own heap, and the mallopt man page notes that a heap can be trimmed only if memory is freed at the top end. One long-lived allocation near the top of an arena keeps all the freed space below it. A multi-threaded Tokio runtime runs work on many threads, so there are many arenas, each holding its own leftovers.

Two fixes, in order of effort:

1. Cap the number of arenas with the MALLOC_ARENA_MAX environment variable, for example MALLOC_ARENA_MAX=2, and measure. Fewer arenas means less memory stuck in leftovers, at the cost of more contention.
2. Switch the global allocator. jemalloc and mimalloc often hold far less memory for this kind of workload, and the switch is a few lines:

// Cargo.toml:
// [target.'cfg(not(target_env = "msvc"))'.dependencies]
// tikv-jemallocator = "0.7"

#[cfg(not(target_env = "msvc"))]
#[global_allocator]
static GLOBAL: tikv_jemallocator::Jemalloc = tikv_jemallocator::Jemalloc;

Whichever you pick, compare RSS under the same load test before and after. Allocator behaviour depends on the workload, and your own numbers are the only argument that counts.

4. Tasks that never finish

The last place is the closest thing to a real leak. Dropping a JoinHandle doesn’t cancel a Tokio task; it detaches it. A spawned loop that waits on a channel whose sender is kept alive somewhere, or that retries forever, keeps its future and everything it captured, often an Arc of shared state, until the process exits.

The tool for this is tokio-console, which its README describes as “like top(1) for tasks”. It needs the tokio_unstable cfg and one line of setup:

// build with: RUSTFLAGS="--cfg tokio_unstable" cargo build
#[tokio::main]
async fn main() {
    console_subscriber::init();
    // ... the rest of your service
}

Run tokio-console next to it and look at task counts and idle times. A count that only grows, or a pile of tasks spawned from the same line that have been idle for hours, points straight at the loop that never exits. The fix is usually an exit condition: a CancellationToken, a channel that gets closed, or a JoinSet whose tasks are aborted when it’s dropped along with its owner.

Where to start

1. Compare RSS with the live heap. If the heap is flat and RSS isn’t, it’s the allocator.
2. Count tasks over time. If the count only grows, find the task that never ends.
3. Look for unbounded queues on the hot path.
4. Measure the futures you spawn per connection or per message.

None of these is a bug the compiler can catch, and none of them shows up in a small test. They appear under real load, a few hours in, so it pays to know where to look before then.

This post is the mental model I use to find out which place it is. None of it is specific to one product; it applies to any system that turns a desktop into a video stream and back.

A remote desktop is a pipeline

Every frame you see goes through the same stages:

1. Schedule. Before there is a desktop at all, the scheduler has to find a node with the right resources and start the session there. This happens once, but it is the first thing users notice.
2. Capture. On the host, the compositor produces frames and the capture layer grabs what changed since the last one.
3. Encode. The frame is compressed with a video codec, on the GPU if the node has a hardware encoder or on the CPU if it doesn't.
4. Transport. The encoded frame crosses the network, along with everything that network brings: round-trip time, jitter and packet loss.
5. Decode. The client turns the bitstream back into pixels, again on either the CPU or the GPU.
6. Present. The decoded frame is converted to the display format and drawn, ideally in step with the monitor’s refresh.

Input travels the other way: a key press goes from the client to the host, the application reacts, and the result comes back through all six stages. What users call lag is the sum of that round trip.

Throughput and latency are different problems

It’s worth separating two numbers that are easy to blur together. Throughput is how many frames per second the pipeline can sustain. Latency is how long a single frame, or a single key press, takes to make it through.

They pull against each other. Buffers smooth out throughput: if decoding occasionally takes too long, a queue of frames hides it. But every buffered frame is a frame of latency. For video playback that trade is fine. For an interactive session it usually isn’t, and it’s better to drop a late frame than to queue it behind others and make everything after it late too.

So when someone reports that a session is slow, the first question is which kind of slow. Choppy motion points at throughput. A delay between moving the mouse and seeing the cursor move points at latency.

CPU or GPU decoding

Decoding is where the CPU-versus-GPU choice gets interesting, because the answer depends on the client, not the server.

Hardware decoding on the GPU, through APIs like D3D11VA or DXVA on Windows, VA-API on Linux or VideoToolbox on macOS, can handle high resolutions at high frame rates while leaving the CPU almost idle. When it works, it’s the best option by a wide margin.

The catch is the word “when”. Hardware decoders differ between vendors, generations and driver versions. Some don’t support every codec profile. Some limit how many streams can decode at once. And there is a trap that quietly eats the benefit: if the decoded frame is copied from GPU memory back to system memory so the CPU can convert and draw it, that copy can cost more than the decode saved. To get the full benefit, the frame should stay on the GPU from decode to present.

Software decoding on the CPU, for example through FFmpeg’s libavcodec, is predictable and runs everywhere, including virtual machines and thin clients without a usable GPU. It scales with cores, but at high resolutions and frame rates it can saturate a laptop CPU, and the colour conversion from the decoder’s output format to RGB adds its own cost.

In practice the answer is to support both and decide at runtime. Probe what the client can actually do, prefer the hardware path, and fall back to software automatically, both when the hardware decoder fails to initialise and when it fails halfway through a session. A fallback users never notice is worth more than a fast path that occasionally freezes.

Measure each stage, not the whole

An end-to-end number tells you that something is slow, not what. What helps is per-stage timing:

• Stamp each frame when it is captured and carry that stamp through the pipeline, so the client can tell how old a frame is when it’s presented.
• Record how long encode, decode and present take, separately from network time.
• Look at percentiles, not averages. A session with a fine average and a bad 99th percentile frame time is a session that stutters, and stutter is what people complain about.
• Log decoder decisions: which path was chosen, and every fallback with its reason.

With that in place, most investigations become short. If frames leave the host on time and arrive late, it’s the network. If they arrive on time and are presented late, it’s the client.

The things that bite

A few problems come up again and again:

• Resolution changes. Plugging in a monitor or resizing a window can force the decoder to reinitialise. If that path isn’t well tested, it’s where sessions freeze.
• Multiple monitors. More pixels, and sometimes several streams, each with its own decoder.
• Refresh-rate mismatches. A stream at one rate shown on a display at another needs careful frame pacing, or motion looks uneven even when no frames are lost.
• The first minute. Scheduling, session start-up and decoder initialisation all happen at once, so a slow start is often several small delays stacked together.

Know which stage you’re in

Performance work on a remote desktop is mostly about locating the problem. The pipeline view gives you the map, per-stage timing tells you where you are on it, and a reliable fallback keeps users working while you fix the fast path. The fix is rarely where you’d guess first, which is exactly why it pays to measure before you change anything.

At Siemens I built a diagnosis tool for exactly this, based on the Model Context Protocol, so an AI assistant can gather and correlate that evidence for whoever is investigating. This post covers the general approach: what MCP is, why it suits diagnostics, and the design rules I’d follow for any tool like it.

What MCP is

The Model Context Protocol is an open protocol for connecting AI applications to the systems they need to work with. An MCP server exposes capabilities; an MCP client, such as a chat assistant or an IDE, connects to it and makes those capabilities available to the model. The messages are JSON-RPC, carried over standard input and output for local servers or HTTP for remote ones.

A server can offer three kinds of things:

• Tools: functions the model can call, each with a name, a description and a JSON Schema for its input.
• Resources: data the client can read, like files or records.
• Prompts: reusable templates for common tasks.

For diagnostics, tools do almost all of the work. The appeal is that you write the integration once, as a server, and any MCP-capable assistant can use it.

Why diagnostics is a good fit

Root-cause analysis is mostly gathering and cross-referencing: look up the session, check the job, read the logs around the failure, compare with the decoder statistics. Each step is simple; the tedium is in doing all of them and keeping the details straight. That’s a good job for a model with well-designed tools, as long as a person still makes the final call.

Design rules for diagnostic tools

Read-only by default. A diagnosis tool should observe, not act. Restarting a session or killing a job may be the right fix, but those actions belong behind a separate, explicit path with a person in the loop. MCP lets you mark tools with a read-only hint, and clients can use it to decide what needs confirmation.

Narrow tools with typed inputs. One tool per question works better than one tool that runs arbitrary queries. Something like:

• get_session_summary(session_id): state, host, timings, codec and decoder, last errors
• get_job_status(job_id): what the scheduler knows about the job
• search_logs(host, since, until, pattern, limit): a bounded window of matching log lines
• get_codec_stats(session_id): frame timings, decoder path and fallbacks

Return summaries, not dumps. Everything a tool returns lands in the model’s context window. Ten thousand raw log lines crowd out the reasoning. Return the relevant part, say how much was left out, and let the model ask for more with explicit limits and pagination.

Write descriptions for the model. The model picks tools by reading their descriptions, so a description should say when to use the tool, not only what it returns. “Use this first when a user reports a broken session” is more useful than “returns session data”.

Treat errors as data. “No session with that ID; check the job output for the correct one” lets the model recover. A stack trace doesn’t.

Return the IDs that connect things. If the session summary includes the job ID and the host, the model can chain into the next tool without guessing.

Redact on the way out. Logs contain user names, paths and sometimes tokens. Strip what the investigation doesn’t need before it leaves the server.

A minimal tool

Here is the shape of one tool using the official TypeScript SDK. The lookup function is a stand-in for whatever read-only data source you have:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'
import { z } from 'zod'

const server = new McpServer({ name: 'session-doctor', version: '0.1.0' })

server.registerTool(
  'get_session_summary',
  {
    description:
      'Summarise one remote desktop session: state, host, codec, decoder ' +
      'and the most recent errors. Use this first when a user reports a ' +
      'broken or slow session.',
    inputSchema: {
      sessionId: z.string().describe('Session ID from the user or the job output'),
    },
    annotations: { readOnlyHint: true },
  },
  async ({ sessionId }) => {
    const summary = await loadSessionSummary(sessionId)
    if (!summary) {
      return {
        content: [{ type: 'text', text: `No session ${sessionId}. Check the job output for the right ID.` }],
        isError: true,
      }
    }
    return { content: [{ type: 'text', text: JSON.stringify(summary, null, 2) }] }
  },
)

await server.connect(new StdioServerTransport())

Most of the effort goes into loadSessionSummary and its siblings: deciding what a useful summary contains, and keeping it small.

What an investigation looks like

Take a typical report: a session froze after a few minutes. With tools like the ones above, the assistant fetches the session summary, sees a decoder fallback shortly before the freeze, pulls the codec statistics to confirm frame times climbing, then searches the client logs in that window and finds the decoder being reinitialised after a display change. The person investigating gets that timeline with the evidence attached, instead of spending the first half hour collecting it.

The assistant doesn’t need to be right every time to be useful. It needs to be fast at gathering, and honest about what it found and what it’s guessing.

Lessons

• Start with three or four tools. Add more when you see the assistant reach for something it doesn’t have.
• Log every tool call. The transcripts show which tools get used, which get misused, and which descriptions need rewriting.
• Test against past incidents. Replaying problems you’ve already solved is the cheapest way to check that the tools lead to the right answer.

MCP doesn’t make diagnosis automatic. It makes the dull part fast, which leaves people more time for the part that needs judgement.

At Siemens I’ve been architecting migrations around agentic workflows, where AI agents analyse services, plan the migration steps and carry out the repetitive refactoring. This post is about how I split that work between agents and people, and the guardrails that make it safe.

Three jobs, three agents

Asking one agent to “migrate this service” gives you a large, unreviewable change. Splitting the work into separate jobs, each with its own output, works much better.

The analyst reads the service and produces an inventory: endpoints, their inputs and outputs, dependencies on other services, data stores, configuration, background jobs. It doesn’t change anything. Its output is a structured document that a person can check against what they know.

The planner turns the inventory into an ordered list of small steps. Each step says what changes, which files it touches, and how to verify it: which tests must pass, which behaviour must stay the same.

The executor takes one step at a time. It makes the change on a branch, runs the checks, and opens a pull request. Then it stops.

People review the inventory, approve the plan, and review every pull request. The agents do the reading and typing; people do the deciding.

Structured output between stages

The inventory and the plan should be data, not prose. A JSON document with a fixed schema can be validated, diffed when the agent reruns, and fed to the next stage without anything getting lost in paraphrase. When the planner refers to an endpoint, it refers to an entry in the inventory, not to its own description of one.

This also makes review faster. Checking forty inventory entries in a table is easier than reading four pages of an agent’s summary.

Guardrails

Tests are the contract. An agent can’t preserve behaviour nobody has written down. If the old service lacks tests, the first steps of the plan are characterisation tests that capture what it does today, including the odd parts. Every later step has to keep them green.

Small diffs. If a pull request takes longer to review than it would have taken to write by hand, the step was too big. Small steps also make failures cheap: you throw away one branch, not a week of work.

Use deterministic tools for deterministic work. Renaming a package or updating an import path across a codebase is a job for a codemod, a compiler or a formatter, not for a model retyping files. The agent’s job is to decide which tool to run and check the result. That keeps changes reproducible and avoids the subtle typos that come from regenerating code.

Limited permissions. Agents work in a sandbox with access to the repository and the test runner. They can open pull requests. They can’t merge, deploy or touch production.

Log everything. Every tool call and every decision goes into a log you can read afterwards. When a step goes wrong, the log tells you whether the plan was wrong or the execution was.

What stays with people

Agents are good at reading a lot of code quickly and at making the same kind of change many times. They are not good at knowing what isn’t in the code:

• behaviour that clients depend on but nobody documented,
• operational context, like which endpoint gets hammered at the end of every month,
• trade-offs between doing it properly and doing it now,
• who owns what, and who needs to be told.

Those questions come up during inventory review and planning, which is exactly why people sign off on both before any code changes.

Is it working?

Two measures tell you a lot. The first is how many agent pull requests merge without changes; if reviewers keep rewriting them, the steps are too vague or the checks too weak. The second is review time per pull request; if it creeps up, the steps are getting too big.

The tooling matters less than the boundaries. Frameworks like Google’s Agent Development Kit make it easy to wire agents and tools together, and protocols like MCP give agents typed access to the systems around them. But what makes the workflow trustworthy is the shape of the work: structured hand-offs, small verified steps, and a person approving every change that ships.

Used that way, agents don’t replace the engineers on a migration. They take away the part of the job that nobody wanted, and leave the part that needed an engineer in the first place.

That rule shapes everything about how you migrate. You can’t replace a service that is serving traffic in one move, so you replace it in many small ones, each of which you can undo. This post is the sequence I follow.

1. Put a routing layer in front

Before writing any new code, make sure every request to the old service passes through something you control: an API gateway, a reverse proxy, or a thin routing service. Clients keep calling the same address; the routing layer decides which implementation answers.

This is the strangler fig pattern. The new service grows around the old one, route by route, until the old one has nothing left to do. The routing layer is what makes each step reversible, so it’s worth getting in place first, even though it changes nothing visible.

2. Write down what the old service actually does

Legacy services do things nobody remembers asking for: a field that is always returned in a certain order, an error code a client parses, a trailing slash that is accepted on one route and not another. Clients depend on these.

So before rebuilding a route, capture its behaviour. Contract tests built from real requests and responses work well, with sensitive data scrubbed. They become the definition of done for the new implementation.

3. Rebuild route by route

Pick a route that is low risk and well understood, and build it in the new service. Resist the urge to fix its design while you’re there. A migration that also changes behaviour is two projects, and when something breaks you won’t know which one caused it. Improve the design after the cutover, when the old implementation is gone.

4. Shadow traffic before real traffic

Once a route passes its contract tests, have the routing layer mirror real requests to the new implementation while the old one keeps answering. The client gets the old response; the new response is compared with it in the background and then discarded.

The comparisons find what the tests missed. Expect noise: timestamps, generated IDs and field ordering will differ legitimately, so the comparer needs rules for what to ignore. Everything else is either a bug in the new service or a behaviour of the old one you didn’t know about, and both are worth knowing before any user sees a response from the new code.

Shadowing only works for reads, or for writes you can make safely twice. For anything with side effects, like sending an email or charging a card, the shadow copy has to stop short of the side effect.

5. Decide where the data lives

Data is usually the hardest part. The simplest option is for old and new services to share the same database during the migration, so there is one source of truth and nothing to reconcile. If the new service needs its own store, don’t write to both from application code; a crash between the two writes leaves them disagreeing. Write to one and propagate changes to the other, through an outbox table or change data capture, then backfill history and check the two stores match before switching reads.

6. Cut over gradually

Move real traffic in steps: one percent, then ten, then half, then all of it, with a flag per route in the routing layer. At each step, watch the numbers that matter to users: error rate, 99th percentile latency, and whatever business metric the route drives. Move on only when they look the same as before.

7. Rehearse the rollback

Rolling back should be one configuration change in the routing layer, and you should have done it at least once on purpose before you need it. A rollback path that has never been exercised is a hope, not a plan.

8. Finish the job

When a route has run on the new service for long enough to trust it, delete the old code for it, remove its flag and its shadowing rules. Migrations that stall at 95 percent are common, and they leave you running two systems indefinitely, which is worse than either one alone.

Why Go and Kotlin

Each target language suited different services. Go fits small, network-heavy services well: fast start-up, low memory use, a strong standard library for HTTP, and goroutines that make concurrent I/O straightforward. Kotlin made sense where teams depended on JVM libraries and frameworks: it keeps all of that and adds null safety, concise syntax and coroutines.

The language mattered less than the sequence, though. Routing layer, recorded behaviour, route-by-route rebuilds, shadow traffic, gradual cutover and a rehearsed rollback would have worked just as well for any other target. They’re what turn a risky rewrite into a series of small, boring changes, and boring is exactly what you want from a migration.

This post explains why duplicates happen and the patterns I use so that every event is processed exactly once in effect, even when it’s delivered twice.

Why duplicates happen

A Kafka consumer reads a message, processes it, and commits its offset so it won’t read that message again. The trouble is the gap between processing and committing. If the consumer crashes, is restarted by a deploy, or loses its partition in a rebalance after processing a message but before committing the offset, the next consumer to own that partition starts from the last committed offset and processes the message again.

Committing before processing just swaps one problem for another: crash at the wrong moment and the message is never processed at all. Producers add duplicates of their own when they retry a send whose acknowledgement got lost.

So the realistic guarantee for the system as a whole is at-least-once delivery. Kafka does offer exactly-once semantics through idempotent producers and transactions, but that covers reading from Kafka and writing back to Kafka. The moment your consumer writes to a database or calls another service, you’re outside it.

Make processing idempotent

An operation is idempotent if doing it twice has the same effect as doing it once. The goal is to make each consumer’s effect idempotent, so redelivery is harmless.

Give every event an ID. The producer assigns a unique ID when the event is created, not when it’s sent, so retries carry the same ID. Put it in a header or in the payload.

Record processed IDs in the same transaction as the effect. If the consumer writes to a relational database, keep a table of processed event IDs and insert into it in the same transaction as the real change. A duplicate hits the primary key and the whole thing is skipped. Because both writes commit together, there’s no window where the effect happened but the ID wasn’t recorded.

func (h *Handler) Handle(ctx context.Context, msg kafka.Message) error {
	tx, err := h.db.BeginTx(ctx, nil)
	if err != nil {
		return err
	}
	defer tx.Rollback()

	// the event ID is the idempotency key; a redelivered event inserts nothing
	res, err := tx.ExecContext(ctx,
		`INSERT INTO processed_events (event_id) VALUES ($1) ON CONFLICT DO NOTHING`,
		eventID(msg))
	if err != nil {
		return err
	}
	if n, err := res.RowsAffected(); err != nil || n == 0 {
		return err // nil when it's a duplicate: already handled
	}

	if err := h.apply(ctx, tx, msg); err != nil {
		return err
	}
	return tx.Commit()
}

The offset is committed only after Handle returns without an error. If the process dies anywhere in between, the transaction rolls back and the message is simply processed again later, safely.

Or make the write itself idempotent. Sometimes you don’t need a separate table. Setting a value is naturally idempotent where incrementing one isn’t: “set the order status to shipped” can run twice, “add 10 to the balance” can’t. Upserts keyed on a natural ID, and updates guarded by a version number so an older event can’t overwrite a newer state, cover a lot of cases.

Producing events safely: the outbox

The mirror-image problem appears when a service changes its database and publishes an event about it. Write to the database and then publish, and a crash in between loses the event. Publish first, and a failed database write leaves an event announcing something that never happened.

The outbox pattern solves it. In the same transaction as the business change, insert the event into an outbox table. A separate relay reads the outbox and publishes to Kafka, marking rows as sent. The relay might publish an event twice if it crashes after sending but before marking, which is fine, because the consumers are idempotent.

Ordering, retries and poison messages

• Ordering. Kafka orders messages only within a partition. If events about the same entity must be processed in order, use the entity’s ID as the message key so they land on the same partition.
• Retries. Transient failures, like a database timeout, deserve a few retries with backoff, inside the consumer, before giving up.
• Poison messages. A message that can never be processed, because it’s malformed or breaks an assumption, will block its partition forever if you keep retrying it. After a bounded number of attempts, move it to a dead-letter topic with the error attached, alert on it, and keep going.

Watch consumer lag

Consumer lag, the distance between the newest message in a partition and the consumer’s committed offset, is the single most useful health metric for an event-driven service. Growing lag means the consumer can’t keep up or is stuck on something. A partition whose lag climbs while the others stay flat usually points to a poison message or a hot key.

The habit

None of these patterns is complicated. The lesson I keep relearning is to assume duplicates from the first line of a consumer, not to add idempotency after the first incident. Ask “what happens if this runs twice?” in every review, and event-driven systems become a lot less surprising.

Teaching changed how I explain things, and it changed how I write code. These are the lessons that stuck.

Start with an example, then name the idea

The instinct is to define a concept and then show an example of it. It almost always works better the other way round. Show a function that calls itself to walk a folder tree, let people follow it, and only then say the word “recursion”. The name lands on something they already understand instead of floating in the air waiting for an example to attach to.

Ask for a prediction before the answer

When someone asks why their code doesn’t work, the fastest route is rarely to tell them. Ask them what they expect it to print, and then run it. The gap between the prediction and the output is exactly where their mental model is wrong, and finding it themselves sticks far better than any explanation I could give.

Let people get stuck, but not for long

Struggling with a problem is how the learning happens, and solving it for someone takes that away. But being stuck for too long just turns into frustration. What worked for me was a ladder of hints: first a question that points in the right direction, then a smaller version of the problem, then the key insight, and only at the very end the solution.

Draw the state

A lot of confusion comes from state people can’t see. For recursion, a table with one row per call and a column per variable makes the call stack visible. For pointers and references, boxes and arrows. For system design, the path of one request through every component, drawn before discussing how to scale anything. Once the state is on the page, most questions answer themselves.

Get to something that works early

Motivation is a resource, and nothing replenishes it like seeing your own program work. The best sessions got students to a running result quickly, even a crude one, and improved it from there. That’s also how I approach new projects now: an ugly end-to-end version first, then refinement.

Make feedback specific

In mock interviews, “you did well” and “work on your communication” help nobody. A scorecard with concrete criteria, such as clarifying the requirements, explaining the approach before coding, testing with an edge case and discussing complexity, makes feedback something a person can act on. It also makes me more consistent: two candidates who do the same thing get the same feedback. The mock interview kit on my GitHub grew out of exactly that.

How it changed my engineering

Teaching taught me that if I can’t explain something simply, I probably don’t understand it well enough yet. That shows up in my work every day:

• Code reviews. I try to explain the why behind a suggestion, and ask questions rather than issue verdicts, the same way I would with a student.
• Naming. A name is a tiny explanation. If a function is hard to name, it usually does too much.
• Design documents. I write them for someone joining the team next year, not for the people in the room today. That forces me to state assumptions I would otherwise leave implicit.
• Debugging. “What did you expect, and what happened instead?” is as useful a question for a production incident as it is for a beginner’s homework.

Why I keep doing it

Every time I explain something, I find a gap in my own understanding. Students ask the questions experienced engineers have stopped asking, and answering them properly keeps me honest. That’s the real reason I’ve kept teaching alongside engineering, and why the low-level design and interview material I use is open on GitHub for anyone who wants it.

When working with databases, accuracy and performance are pivotal, especially when handling numbers. PostgreSQL, a robust and versatile relational database, offers several numeric data types, each tailored to different use cases. Among these, the NUMERIC type shines as a tool for handling precise calculations. In this post, we’ll explore the NUMERIC type, its benefits, and how it compares to other numeric types in PostgreSQL.

What is the NUMERIC Type in PostgreSQL?

The NUMERIC type in PostgreSQL is a high-precision, arbitrary-scale data type designed to store numbers without losing accuracy. It is ideal for use cases where exactness is non-negotiable, such as:

• Financial transactions
• Scientific calculations
• Engineering applications

With NUMERIC, you can specify precision (total number of digits) and scale (number of digits after the decimal point). For example:

CREATE TABLE transactions (
    id SERIAL PRIMARY KEY,
    amount NUMERIC(10, 2) -- up to 10 digits, 2 of which are after the decimal
);

This ensures that no rounding errors creep into calculations, making it perfect for critical systems.

Key Features of NUMERIC

1. User-Defined Precision and Scale
   You can tailor the type to fit your specific requirements:

• NUMERIC(10, 2) allows values like 12345.67.
• Without specification, NUMERIC can hold any value with arbitrary precision.

1. Guaranteed Accuracy
   Unlike floating-point types (REAL, DOUBLE PRECISION), which approximate values, NUMERIC stores data exactly as entered.
2. Extensive Range
   With a virtually unlimited range of values, NUMERIC can handle data that exceeds the capacity of standard integer types.

When to Use NUMERIC

The NUMERIC type is your go-to choice when precision is a top priority. Here are some specific scenarios:

1. Finance
   Calculating interest rates, balances, and taxes requires precision. Even tiny rounding errors can lead to significant discrepancies.
2. Scientific Research
   Fields like physics or chemistry often demand exactness in measurements and calculations.
3. Compliance
   Industries with regulatory requirements (e.g., healthcare, banking) may require the use of precise, non-approximated data storage.

Performance Considerations

While the NUMERIC type ensures precision, it comes with a trade-off: performance. It uses more storage than fixed-width types (INTEGER, BIGINT) and takes longer to process due to its flexible precision. For high-speed applications where slight inaccuracies are tolerable, floating-point types like REAL or DOUBLE PRECISION may be preferable.

To optimize performance:

• Use NUMERIC only when precision is required.
• Leverage indexes to speed up searches and calculations on NUMERIC columns.

Tips for Using NUMERIC Effectively

1. Specify Precision and Scale Where Possible
   Defining precision and scale not only improves clarity but also optimises storage.

CREATE TABLE orders ( order_id SERIAL PRIMARY KEY, total_price NUMERIC(15, 2) );

1. Avoid Overusing It
   Use NUMERIC sparingly for large-scale datasets that don’t need exact precision to save storage and processing power.
2. Combine with Constraints
   Add constraints to ensure data integrity. For example:

CHECK (amount >= 0)

Conclusion

PostgreSQL’s NUMERIC type is a powerful ally for applications that demand precision. Its ability to handle arbitrary precision and scale makes it indispensable for fields like finance and science. However, it’s essential to balance its accuracy with the performance demands of your application.

By understanding the strengths and trade-offs of NUMERIC and its alternatives, you can make informed decisions that optimize both the reliability and efficiency of your database. For developers who value precision, NUMERIC is not just a data type—it’s peace of mind.

Originally published on Medium.

Introduction

In today’s world of rapid tech growth, scalability is essential. Modern applications need to handle increasing traffic, complex data processing, and real-time demands without compromising performance. Golang, or Go, has emerged as a powerful tool for building scalable, high-performance systems. Its lightweight nature, efficient concurrency model, and simple syntax make it a go-to choice for backend development, cloud-native services, and microservices architectures.

This article delves into why Go is well-suited for scalable applications, exploring its core features, concurrency handling, garbage collection, and real-world examples from companies that rely on Go for their high-traffic systems. Whether you’re starting with Go or looking to deepen your understanding of its scalability strengths, this article offers insights and best practices for leveraging Go in scalable system design.

1. Why Go is Designed for Scalability

Go was designed by Google engineers for large-scale systems. It emphasizes simplicity and speed, with specific features that make it ideal for scalable architecture:

• Lightweight Goroutines: Goroutines are Go’s method for handling concurrency. Unlike traditional threads, they are lightweight and don’t require large memory allocation, which allows you to manage thousands or even millions of concurrent tasks.
• Efficient Garbage Collection: Go’s garbage collector is optimized for concurrent workloads. It reduces memory leaks by reclaiming unused memory, which is crucial for long-running applications that handle a lot of traffic.
• Minimalist Syntax: Go’s simple syntax improves readability and maintainability, which is essential for scaling projects and teams.
• Compilation Speed: Go’s compiler is fast, allowing developers to quickly iterate and deploy, which is valuable in high-growth environments.

With these foundational features, Go helps companies develop applications that can scale both in terms of performance and development agility.

2. Concurrency and Parallelism in Go

Concurrency is a cornerstone of scalability, and Go’s concurrency model is one of its standout features.

• Goroutines and Channels: Goroutines are functions that run independently of the main thread, allowing applications to handle numerous tasks concurrently. Channels provide a means of safe communication between goroutines, enabling structured concurrency that prevents common issues in multithreaded programming.
• Cost-Effective Parallel Processing: Unlike languages that rely on OS-level threads, goroutines are managed by Go’s runtime. This lowers the cost of context-switching, reducing the overhead of running multiple tasks and making parallel processing efficient for applications with large workloads.
• Practical Example: In a web server, each request can be handled by a separate goroutine. This allows the server to handle thousands of requests simultaneously without stalling, providing a seamless experience for users even during high-traffic periods.

By adopting Go’s concurrency tools, developers can build systems that handle concurrent tasks efficiently, meeting high demand without increased complexity or resource consumption.

3. Real-World Scalability with Go: Case Studies

Numerous tech giants use Go to scale their applications to millions of users. Let’s explore some notable examples:

• Google: Google uses Go for many of its internal systems, given Go’s strong support for high-performance, concurrent applications. Services like Kubernetes also rely on Go, demonstrating its effectiveness in handling complex, distributed systems.
• Uber: Uber chose Go to build its geofence service. Go’s low-latency concurrency allowed Uber to handle location-based traffic efficiently, ensuring ride requests and driver availability updates are processed in real time.
• Dropbox: Dropbox migrated to Go for its backend infrastructure, leading to more manageable code and improved performance. Go’s simple syntax helped Dropbox developers enhance team productivity as they scaled the service.
• Netflix: Netflix uses Go for tasks that require high concurrency, such as handling network operations in its streaming services. Go’s lightweight concurrency allows Netflix to manage numerous simultaneous connections, providing smooth streaming experiences.

These examples illustrate how Go’s concurrency, simplicity, and performance have enabled some of the most popular and high-traffic services to scale effectively.

4. Scalable Patterns and Practices in Go

Building a scalable application with Go requires adopting design patterns and best practices that suit its strengths. Here are a few key patterns:

• Microservices: Go is widely used for microservices due to its performance and modularity. Each service can run independently, making it easier to scale horizontally by adding more instances as demand grows.
• Load Balancing and Caching: Implement caching mechanisms and load balancers to distribute the workload across multiple services. This optimises resources, enabling systems to handle increased load without downtime.
• Graceful Shutdowns and Signal Handling: Gracefully shutting down services is crucial for scaling applications in production. Using context and signal packages in Go, developers can manage shutdowns, preventing abrupt service interruptions during high loads.
• Testing for Scalability: Performance testing tools like GoBench and GoTest help identify bottlenecks and optimize performance under load. Writing load tests allows developers to simulate real-world traffic and make adjustments before scaling applications in production.

With these patterns, you can create scalable Go applications ready to handle growth, adapt to demand, and maintain consistent performance.

5. Optimising Performance in Go for Scalability

Performance optimisation is crucial for scalability, and Go provides several tools and techniques to streamline this process:

• Profiling Tools: Go’s pprof tool can profile CPU, memory, and goroutine usage, allowing developers to identify bottlenecks. For more granular insights, the trace package can analyze function call times and memory allocations.
• Reducing Memory Leaks: Go’s garbage collection helps reduce memory leaks, but developers should still watch for resource-hogging patterns. For instance, using sync.Pool to reuse temporary objects can help minimise memory usage in concurrent applications.
• Optimising Network Calls: For microservices or web applications, optimising network calls using HTTP keep-alives and persistent connections can reduce latency. Additionally, using efficient JSON encoding/decoding libraries like easyjson can help handle large amounts of data without adding excessive latency.

These optimisations can ensure your Go applications maintain high performance as they scale, providing users with faster, more responsive services.

Conclusion

Go’s design philosophy, rooted in simplicity and efficiency, makes it an excellent choice for building scalable systems. Its concurrency model, efficient garbage collection, and straightforward syntax enable developers to build high-performance applications that grow alongside user demand. Companies like Google, Uber, Dropbox, and Netflix have harnessed Go’s capabilities to build and scale their services effectively.

Whether you’re building a microservice architecture, handling real-time data processing, or just starting with Go, embracing Go’s strengths and best practices will help you create scalable solutions tailored for today’s high-demand environment. The Go ecosystem is continually evolving, so keep exploring and optimizing as you scale your applications to new heights.

Originally published on Medium.

Introduction

In recent years, Go has risen in popularity as a powerful language for backend and cloud-native applications. While many developers are aware of Go’s fundamental tools (go run, go test, go fmt, etc.), fewer know about the advanced tools that can supercharge productivity and elevate the quality of Go applications. This article will introduce a curated list of advanced tools that cover various stages of the Go development lifecycle, from dependency management to code analysis, testing, and performance optimisation.

By integrating these tools, Go developers can speed up workflows, catch issues early, and fine-tune applications for better performance. Whether you’re building high-scale micro-services or diving into Go for your next project, these tools will help you get the most out of the Go ecosystem.

1. Dependency Management: Go Modules and Gopkg.lock

Go Modules, introduced in Go 1.11, is the go-to (pun intended) dependency management system for Golang. While Go Modules is familiar to many, understanding advanced usage of go.mod and go.sum can simplify complex projects.

• Go Modules Basics: go mod init initialises a module, while go mod tidy cleans up dependencies.
• Advanced Tips: Use go mod vendor to create a local vendor folder, ensuring dependencies are locked and offline-ready for CI/CD pipelines.
• Version Control: Tools like modver can help validate version constraints, avoiding potential dependency issues.

Beyond Go Modules, some developers find gopkg.lock (from dep) helpful for legacy projects. Using these alongside Go Modules can provide finer control over dependencies in mono-repos or legacy codebases.

2. Code Linting and Static Analysis: golangci-lint

Writing clean, maintainable code is critical, and linting tools help enforce best practices. golangci-lint is one of the most powerful tools for Go, offering static analysis and linting with minimal configuration.

• Why golangci-lint? It combines multiple linters (like errcheck, gosimple, unused) into a single tool, making it easy to catch potential issues.
• Features: Supports custom rules, plugins, and inline //nolint comments for more control.
• Performance: golangci-lint caches results and uses concurrent processing, which makes it faster for large projects.

To integrate, simply run golangci-lint run in your terminal, or configure it in CI/CD pipelines to catch errors before code merges.

3. Advanced Testing: Testify and Ginkgo

Testing is crucial in production-grade code, and while the standard library’s testing package is robust, tools like Testify and Ginkgo take testing in Go to the next level.

• Testify: Offers powerful assertion libraries (assert, require) and mock creation, making it ideal for writing expressive tests. It’s a lightweight addition to the standard testing package and fits well in unit testing workflows.
• Ginkgo: For behavior-driven development (BDD), Ginkgo provides a framework that allows structuring tests in a more expressive way. Use Gomega, an assertion library built for Ginkgo, to create readable, intention-driven tests.

These tools enhance test readability and make writing, organising, and managing tests more efficient, especially for complex projects.

4. Profiling and Performance Optimization: pprof and trace

Optimizing Go code is crucial for high-performance applications, and pprof is Go’s built-in tool for profiling CPU, memory, and goroutine performance.

• CPU and Memory Profiling: By adding import _ "net/http/pprof" and enabling it in your app, you can visualize CPU and memory usage in real time.
• Flame Graphs: pprof integrates with tools like go-torch to generate flame graphs, making it easy to identify bottlenecks.
• Tracing: Go’s trace package provides a lower-level analysis of goroutines, system calls, and scheduling events. It’s useful for diagnosing hard-to-track concurrency issues in production environments.

These profiling tools are crucial for developers focused on high-performance applications and can quickly reveal inefficient code paths.

5. Package Management and Dependency Analysis: godepgraph and go-callvis

Understanding dependencies and code structure is essential for maintainability. godepgraph and go-callvis are two visualization tools that make it easy to analyze and improve code organization.

• godepgraph: Generates dependency graphs that help understand module-level relationships and detect dependency cycles.
• go-callvis: A tool for visualizing function calls and package interactions within a Go program. Ideal for understanding complex interactions, go-callvis generates call graphs that clarify which functions interact and where.

These tools are invaluable for debugging and can provide insight into potential architectural improvements.

6. Code Generation: Goa and Gobuffalo

In projects that require a lot of boilerplate code, code generators save time and reduce errors.

• Goa: A framework for creating RESTful microservices with a design-first approach. Define API contracts, and Goa will generate corresponding server code.
• Gobuffalo: Primarily known as a web framework, Gobuffalo includes a code generation CLI that creates boilerplate code for web components, middleware, and services.

Using code generation tools reduces the amount of repetitive code you need to write, especially useful in micro-services and REST API projects.

7. Documentation and Code Browsing: godoc and GoSwagger

Documentation is key to maintainability, and Go offers built-in and third-party tools to keep it streamlined.

• godoc: Go’s built-in documentation generator, which serves as a mini web server, letting you browse package documentation locally.
• GoSwagger: For APIs, GoSwagger reads OpenAPI definitions and generates Go code for clients and servers, making it easier to keep documentation synchronized with code.

These tools improve code comprehension and are essential for onboarding and maintaining code quality.

Conclusion

With these advanced tools, Go developers can tackle complex challenges, optimise their workflows, and produce high-quality code. From dependency management to code generation and profiling, these tools cover every aspect of the development cycle. By leveraging these tools effectively, developers can build more robust, scalable, and efficient applications with Go.

Explore the possibilities and start integrating these tools into your workflow. The Go ecosystem is ever-evolving, and by staying updated with the latest tools, you can ensure that your Go projects are built for the future.

Originally published on Medium.