Building Spatial Memory: Why I Built a "Pinterest for the Physical World" and What I Learned

Honestly, I've had this idea in the back of my head for years.

What if you could leave notes, photos, and stories for people to find only when they physically stand where you stood? Like digital geocaching, but more social, more personal. A "spatial memory network" where memories are anchored to the real world.

I finally built it after three months of late nights, and today I want to share what I learned, what went wrong, and what I'd do differently if I started over.

If you're curious, the code is open source here: https://github.com/kevinten10/spatial-memory

The Idea That Wouldn't Die

I was hiking last year, stopped at this incredible viewpoint, and thought to myself: "I wish I could read what other people thought about this place before I got here. And I wish I could leave something for the next person."

Most photo apps let you geotag, but that's not the same. Everything is still in your feed, discoverable by anyone anywhere. The magic is in the proximity — you have to be here to unlock what people left here.

So here's the core concept:

• Pin memories (photos, videos, text, voice) to GPS coordinates
• Only people within ~50 meters can actually see the full content
• Progressive privacy: Private → Friends-only → Public
• Think of it as "location-based time capsules" that humanity collectively fills

It sounded simple enough. Spoiler: it was not that simple.

The Tech Stack I Ended Up With

So here's the thing about spatial apps — you need specialized tooling that most backend projects don't. Let me walk you through what I picked and why.

1. Database: PostgreSQL + PostGIS was a no-brainer

If you need to do proximity searches ("find all memories within 50 meters of me"), you need spatial indexes. Sure, you could store lat/lng as floats and do haversine calculations in application code, but that's insanity at any scale.

PostGIS gives you:

• Spatial indexing with R-tree
• Built-in distance calculations
• Proximity queries out of the box
• It's just PostgreSQL — you already know it

Here's what the table looks like:

CREATE TABLE public_memories (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    location GEOGRAPHY(POINT, 4326) NOT NULL,
    title VARCHAR(255) NOT NULL,
    description TEXT,
    media_urls TEXT[] NOT NULL DEFAULT '{}',
    visibility VARCHAR(20) NOT NULL DEFAULT 'private',
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- Create spatial index for proximity queries
CREATE INDEX idx_public_memories_location ON public_memories USING GIST (location);

And here's how you actually do the proximity query in Go:

package repository

import (
    "context"
    "fmt"
    "github.com/jackc/pgx/v5/pgxpool"
    "github.com/kevinten10/spatial-memory/internal/models"
)

func (r *MemoryRepository) FindNearby(
    ctx context.Context,
    lat float64,
    lng float64,
    radiusMetres float64,
    limit int,
) ([]models.PublicMemory, error) {
    // PostGIS makes this SO clean
    query := `
        SELECT id, title, description, media_urls, visibility, created_at,
               ST_X(location::geometry) AS lat, ST_Y(location::geometry) AS lng,
               ST_Distance(location, ST_SetSRID(ST_MakePoint($1, $2), 4326)) AS distance
        FROM public_memories
        WHERE visibility = 'public'
        AND ST_DWithin(location, ST_SetSRID(ST_MakePoint($1, $2), 4326), $3)
        ORDER BY distance ASC
        LIMIT $4;
    `

    rows, err := r.pool.Query(ctx, query, lng, lat, radiusMetres, limit)
    if err != nil {
        return nil, fmt.Errorf("find nearby: %w", err)
    }
    defer rows.Close()

    var memories []models.PublicMemory
    for rows.Next() {
        var m models.PublicMemory
        err := rows.Scan(
            &m.ID, &m.Title, &m.Description, &m.MediaURLs,
            &m.Visibility, &m.CreatedAt, &m.Lat, &m.Lng, &m.Distance,
        )
        if err != nil {
            return nil, err
        }
        memories = append(memories, m)
    }

    return memories, nil
}

That's it. That's your entire proximity search. PostGIS does all the heavy lifting.

2. Caching: Redis GEO for Hot Zones

Here's a problem I didn't anticipate: popular tourist spots get hammered with proximity queries all the time. You don't want to hit PostGIS for the same query every 2 seconds.

Redis has native GEO commands built in since version 3.2. I use it to cache memory IDs in popular areas:

package cache

import (
    "context"
    "github.com/redis/go-redis/v9"
)

type SpatialCache struct {
    rdb *redis.Client
}

func (c *SpatialCache) AddMemory(ctx context.Context, id string, lat float64, lng float64) error {
    // Add to Redis GEO
    return c.rdb.GeoAdd(ctx, "spatial:memories", &redis.GeoLocation{
        Name:      id,
        Longitude: lng,
        Latitude:  lat,
    }).Err()
}

func (c *SpatialCache) GetNearbyIDs(ctx context.Context, lat float64, lng float64, radiusMetres float64) ([]string, error) {
    // Get nearby memory IDs within radius
    res, err := c.rdb.GeoRadius(ctx, "spatial:memories", lng, lat, &redis.GeoRadiusQuery{
        Radius: radiusMetres,
        Unit:   "m",
        Count:  50,
        Sort:   "ASC",
    }).Result()

    if err != nil {
        return nil, err
    }

    ids := make([]string, len(res))
    for i, loc := range res {
        ids[i] = loc.Name
    }

    return ids, nil
}

Pro tip: Don't cache the entire memory object in Redis, just the IDs. You still go to PostgreSQL for the actual data. This keeps Redis memory usage tiny while still cutting down query time from ~20ms to ~2ms.

3. Object Storage: Cloudflare R2 was the right call

Uploading user photos and videos — if you proxy them through your backend API, your server gets crushed instantly.

I went with the two-phase upload pattern:

1. Client asks server for a pre-signed URL
2. Server signs and returns a direct R2 upload URL
3. Client uploads directly to R2 (never touches your API)
4. Client confirms to server that upload is complete

This is how you do it with the S3-compatible API in Go:

package storage

import (
    "context"
    "fmt"
    "github.com/aws/aws-sdk-go-v2/aws"
    "github.com/aws/aws-sdk-go-v2/credentials"
    "github.com/aws/aws-sdk-go-v2/service/s3"
    "time"
)

type R2Storage struct {
    client   *s3.Client
    bucket   string
    publicURL string
}

func (r *R2Storage) GetUploadURL(ctx context.Context, fileName string, contentType string, expiresIn int) (string, error) {
    req, err := r.client.PutObjectRequest(ctx, &s3.PutObjectInput{
        Bucket:      aws.String(r.bucket),
        Key:         aws.String(fmt.Sprintf("uploads/%s", fileName)),
        ContentType: aws.String(contentType),
    })

    if err != nil {
        return "", err
    }

    url, _, err := req.Presign(time.Duration(expiresIn) * time.Second)
    if err != nil {
        return "", err
    }

    return url, nil
}

func (r *R2Storage) GetPublicURL(key string) string {
    return fmt.Sprintf("%s/%s", r.publicURL, key)
}

Why R2 instead of S3? No egress fees. That's it. For an app with user-uploaded media, egress fees can eat your lunch. R2 gives you zero egress and S3 compatibility. Win-win.

4. AI Moderation: GLM-4V for Image Content

Since this is a public app with user-uploaded images, you need moderation. I went with GLM-4V from ZhipuAI because it's cheap and good enough for this use case.

The prompt I use is straightforward:

prompt := `
Please check if this image contains any inappropriate content:
- Illegal activities
- Nudity or sexual content
- Violence or graphic injury
- Hate speech or harassment
- Dangerous goods or regulated substances

If everything is safe, respond only with "SAFE". If it's not safe, respond only with "UNSAFE: reason".
`

So far, it's caught 98% of the bad stuff I've thrown at it. Is it perfect? No. But it's good enough for a side project.

The Surprising Hard Parts

Let me be honest — I underestimated how many weird edge cases you hit when building a location-based app.

1. Coordinate Precision is Tricky

GPS coordinates can be accurate to 10+ decimal places, but do you need that precision? Turns out:

• 6 decimal places ≈ 10 centimeters precision
• 5 decimal places ≈ 1 meter
• 4 decimal places ≈ 10 meters

I store full double-precision in PostGIS (it just works), but when caching in Redis, I round to 6 decimals. No point wasting space on precision you can't actually use.

2. Privacy is More Complex Than You Think

When you pin a memory to GPS coordinates, that's data about a physical place. If people start pinning memories to their homes, you have to be careful. That's why I added three visibility levels:

• Private: Only you can see it
• Circle: Only friends in your circle can see it
• Public: Anyone within 50 meters can see it

Progressive visibility solves most privacy issues. People can choose how exposed they want to be.

3. Authentication for Mobile Apps is Annoying

I wanted to support both SMS login and WeChat OAuth for the Chinese market. That means you need to handle multiple auth methods. I ended up with JWT tokens supporting both:

package auth

import (
    "time"
    "github.com/golang-jwt/jwt/v5"
)

type Claims struct {
    UserID   string `json:"user_id"`
    AuthType string `json:"auth_type"` // "sms" or "wechat"
    jwt.RegisteredClaims
}

func GenerateToken(userID string, authType string, secret string, ttlHours int) (string, error) {
    claims := Claims{
        UserID:   userID,
        AuthType: authType,
        RegisteredClaims: jwt.RegisteredClaims{
            ExpiresAt: jwt.NewNumericDate(time.Now().Add(time.Duration(ttlHours) * time.Hour)),
            IssuedAt:  jwt.NewNumericDate(time.Now()),
        },
    }

    token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
    return token.SignedString([]byte(secret))
}

Not rocket science, but it adds up. Mobile apps expect smooth auth, and third-party OAuth always has surprises.

Pros and Cons: Honest Review

I learned the hard way, so let me save you some time. Here's what's good and what's not about this approach.

✅ Pros

1. PostGIS + Redis GEO is a killer combo — You get spatial queries that are actually fast, and both are mature tools you probably already know. No weird specialized databases needed.

2. Direct-to-R2 uploads scales like crazy — My backend can handle 100x more traffic because it never touches the actual file bytes. This pattern is underrated.

3. Go + Gin is perfect for this — Compiles to a single binary, low memory usage, fast HTTP responses. All you want for a backend API.

4. Progressive visibility solves privacy concerns — Users get control, you get less compliance headache. Everyone wins.

5. Open source stack has no vendor lock-in — All components are self-hostable. You can run this on your own VPS for a few dollars a month.

❌ Cons

1. GPS accuracy is still inconsistent — Urban canyons (tall buildings) mess with GPS. Sometimes people have to walk 10 meters away from where they're supposed to be to unlock a memory. Not much you can do about it.

2. Cold start problem is real — The app is useless until there are enough memories in enough places. Chicken and egg. You need a critical mass before it's actually fun to use.

3. Moderation is never "done" — Even with AI, you still need human review for edge cases. This is ongoing work, not a set-it-and-forget-it feature.

4. Mobile clients are half the battle — I built the backend, but building a good mobile AR experience that actually finds your location reliably is way more work than the backend. If you're thinking of forking this, be prepared.

Would I Do It Again?

Absolutely. It's a side project that scratches an itch I've had for years. Does it have product-market fit? I honestly don't know. Most people I tell the idea to think it's cool, but that doesn't mean they'll actually use it every day.

But that's okay. That's what side projects are for. I learned a ton about spatial databases, which I'd never really used professionally before. That alone was worth the three months of late nights.

The biggest lesson I walked away with? Physical location is an underrated dimension for social apps. Everything is in your feed now, everything is global. There's something magical about tying digital content to actual places. It makes the world feel layered, story-rich, more connected.

I've already left memories at my favorite hiking spots and coffee shops. One day, I hope someone stumbles across them and smiles. That's the whole point.

Your Turn

Have you ever built anything location-based? Ever had an idea for "pinning digital content to physical places"? Do you think this is something you'd actually use when you travel or hike? I'm genuinely curious to hear what you think — drop a comment below!

The code is all open source if you want to play with it or fork it: https://github.com/kevinten10/spatial-memory

Happy building 🗺️