I build reliable software for real-world problems.

A map-based product needed to answer “what points of interest are near this location?” and “what is inside this area?” for a growing dataset, with results returned quickly enough to feel instant as the user pans. POI data came from OpenStreetMap extracts and internal sources with different schemas.

A single Spring Boot service owns the POI domain. PostgreSQL with PostGIS is the source of truth; a scheduled import pipeline normalises source data into it. Clients (Angular admin, mobile/web map) talk only to the REST API through an Nginx reverse proxy.

• Geometry stored as geography(Point, 4326) so distance queries are in metres without manual reprojection.
• GiST index on the geometry column; B-tree indexes on category and status for combined filters.
• Read endpoints are stateless and cacheable at the proxy for identical bounding boxes.

Spatial queries are written as native queries in Spring Data repositories rather than forced through JPQL, keeping the SQL explicit and easy to EXPLAIN. Bounding-box requests use ST_MakeEnvelope + the && operator to hit the index first, then ST_DWithin for exact radius filtering.

SELECT id, name, category,
       ST_Distance(geom, ST_MakePoint(:lng, :lat)::geography) AS distance_m
FROM   poi
WHERE  status = 'ACTIVE'
  AND  ST_DWithin(geom, ST_MakePoint(:lng, :lat)::geography, :radius_m)
ORDER  BY distance_m
LIMIT  :limit;

The obvious approach worked on a small table and fell over as data grew.

• ORDER BY distance over a large radius forced full sorts — solved by tightening the radius server-side and paginating with a distance cursor.
• Importing multi-gigabyte OSM extracts through the ORM was slow and memory-hungry — replaced with streaming parsing and batched COPY-style inserts.
• Mixed SRIDs from different sources produced silently wrong distances until validation was added at import time.

Explicit SQL with the right index types, a streaming import pipeline with idempotent upserts, and API contracts that constrain what clients can ask for (max radius, max page size). Validation happens once at the boundary, so the query path stays simple.

Nearby and area queries stayed responsive as the dataset grew, and imports became a routine scheduled job instead of a manual event. [PLACEHOLDER] Add measured numbers here if you have them — e.g. p95 latency before/after, dataset size, import time.

An internal administrative system needed multiple user types with different permissions across organisations, a proper audit trail, and an API safe enough to expose to a browser frontend and, later, to other services.

Spring Security with stateless JWT access tokens and rotating refresh tokens. Authorization is modelled as roles that group fine-grained permissions; endpoints and service methods are guarded by permission, not by role, so new roles are data rather than code.

• Tables: user, role, permission, role_permission, user_role (scoped by organisation).
• Short-lived access token; refresh token stored hashed with revocation support.
• Permission checks via method security annotations, with a custom evaluator for organisation scope.

A single authentication filter validates the JWT and loads a lightweight principal with the user's permission set. Controllers stay thin; service methods declare the permission they need.

@PreAuthorize("hasPermission(#orgId, 'ORG', 'user:write')")
public UserDto updateUser(Long orgId, Long userId, UpdateUserRequest req) {
    User user = users.findByIdAndOrgId(userId, orgId)
        .orElseThrow(() -> new NotFoundException("user"));
    user.applyChanges(req);
    audit.record(AuditAction.USER_UPDATED, user);
    return UserDto.from(user);
}

Security work is mostly about the details that don't show up in a feature list.

• Preventing cross-organisation data access — every query is scoped by organisation, never trusted from the request body.
• Consistent error responses so the API doesn't leak whether a resource exists to an unauthorised caller.
• Input validation and size limits at the boundary; rate limiting at Nginx for auth endpoints.

A permission model that product people could reason about, enforced in one place, with audit logging on every sensitive action. Security headers and TLS termination handled at the reverse proxy so the application configuration stays focused.

New roles are added through the admin UI rather than a release, and the same API is consumable by other internal clients. [PLACEHOLDER] Add any concrete outcome — e.g. an audit or pen-test pass, or number of roles/orgs supported.

A service that worked on a laptop needed to run reliably on an Ubuntu server: reproducible builds, HTTPS, restarts on failure, and a way to ship updates without downtime surprises.

Multi-stage Docker build producing a slim JRE image. Docker Compose runs the app and PostgreSQL/PostGIS on a private network; Nginx on the host terminates TLS and reverse-proxies to the app. Data lives in named volumes; backups are a scheduled pg_dump.

• App container is non-root, health-checked, and restarted automatically.
• Nginx handles gzip, security headers, request size limits and basic rate limiting.
• Configuration and secrets come from environment files, never baked into images.

The Nginx block is small and boring on purpose.

server {
    listen 443 ssl http2;
    server_name api.example.com;

    ssl_certificate     /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;

    client_max_body_size 50m;
    limit_req zone=api burst=20 nodelay;

    location / {
        proxy_pass         http://127.0.0.1:8080;
        proxy_set_header   Host $host;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto https;
        proxy_read_timeout 60s;
    }
}

Most of the friction came from things that only show up in production.

• Large file uploads timing out at the proxy — required aligning limits and timeouts across Nginx and Spring.
• JVM memory limits inside containers — set explicit heap flags instead of trusting defaults.
• Log noise — structured logs with rotation so disk didn't quietly fill up.

A documented, repeatable deployment: build image → push → pull → compose up, with health checks gating the switch. Runbooks for the two or three things that actually go wrong.

Deployments became a routine few-minute task and the service ran unattended. [PLACEHOLDER] Add uptime, deploy frequency, or incident numbers if you tracked them.