Jānis Ošs’ Post

𝗝𝗮𝘃𝗮 𝟮𝟭 𝗷𝘂𝘀𝘁 𝗯𝗲𝗰𝗮𝗺𝗲 𝗟𝗧𝗦. 𝗝𝗮𝘃𝗮 𝟮𝟱 𝗶𝘀 𝗮𝗹𝗿𝗲𝗮𝗱𝘆 𝗮𝗿𝗼𝘂𝗻𝗱 𝘁𝗵𝗲 𝗰𝗼𝗿𝗻𝗲𝗿.  𝗠𝗼𝘀𝘁 𝘁𝗲𝗮𝗺𝘀 𝗮𝗿𝗲 𝘀𝘁𝗶𝗹𝗹 𝗼𝗻 𝗝𝗮𝘃𝗮 𝟭𝟭. That gap is a ticking clock - not a badge of stability. I've seen systems processing $50M/month still running on JDK 11 because "it works." 𝑰𝒕 𝒅𝒐𝒆𝒔 𝒘𝒐𝒓𝒌. 𝑼𝒏𝒕𝒊𝒍 𝒊𝒕 𝒅𝒐𝒆𝒔𝒏'𝒕. Here's what the modernization wave actually means for backend engineers: 𝗩𝗶𝗿𝘁𝘂𝗮𝗹 𝗧𝗵𝗿𝗲𝗮𝗱𝘀 (𝗣𝗿𝗼𝗷𝗲𝗰𝘁 𝗟𝗼𝗼𝗺) 𝗮𝗿𝗲𝗻'𝘁 𝗷𝘂𝘀𝘁 𝗮 𝗳𝗲𝗮𝘁𝘂𝗿𝗲 - 𝘁𝗵𝗲𝘆'𝗿𝗲 𝗮𝗻 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝘀𝗵𝗶𝗳𝘁. We replaced reactive WebFlux boilerplate in one service with virtual threads. Same throughput. Simpler code. Easier onboarding. 𝗣𝗮𝘁𝘁𝗲𝗿𝗻 𝗠𝗮𝘁𝗰𝗵𝗶𝗻𝗴 + 𝗥𝗲𝗰𝗼𝗿𝗱𝘀 𝗮𝗿𝗲𝗻'𝘁 𝗰𝗼𝘀𝗺𝗲𝘁𝗶𝗰 𝘀𝘂𝗴𝗮𝗿. In DDD, they let your domain model express intent clearly - no more 6-line null checks around a simple type branch. 𝗚𝗿𝗮𝗮𝗹𝗩𝗠 𝗻𝗮𝘁𝗶𝘃𝗲 𝗶𝗺𝗮𝗴𝗲𝘀 𝗮𝗿𝗲 𝗿𝗲𝗮𝗹 𝗻𝗼𝘄. We cut startup time by 60% on a Spring Boot microservice. Cold-start penalties in Kubernetes? Gone. 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀: 🔄 Upgrade path matters more than upgrade speed - test your Kafka serializers and Hibernate dialect first ⚡ Virtual threads will obsolete most reactive code in I/O-heavy services 🏗️ Java 25 isn't disruption - it's the platform finally catching up to what we've been building workarounds for The teams that modernize incrementally win. The ones who wait for "the perfect migration window" fall two LTS cycles behind. Where is your team on the Java upgrade journey? Still on 11? Already on 21? What's the biggest blocker - legacy dependencies, risk appetite, or just bandwidth? #Java #SpringBoot #Microservices #BackendDevelopment #SoftwareEngineering #Kafka #SystemDesign #SoftwareArchitecture #Backend #Ascertia

Logging in Spring Boot: Not Just for Debugging 🚀 When building applications with Spring Boot, logging often starts as a simple tool to print messages during development. But in real-world systems, logging becomes much more than that — it’s your window into how your application behaves in production. Here’s why logging is essential: 🔍 Debugging & Troubleshooting When something goes wrong, logs are the first place you look. A well-structured log can help you quickly identify the root cause without needing to reproduce the issue. 📊 Monitoring & Observability Logs provide insights into application flow, performance bottlenecks, and unusual patterns. Combined with monitoring tools, they help you stay proactive rather than reactive. 🔐 Security & Auditing Tracking user actions, login attempts, and critical operations through logs helps in auditing and detecting suspicious activities. ⚙️ Production Support In distributed systems or microservices, you can’t rely on breakpoints. Logs act as your primary source of truth to understand inter-service communication and failures. “Code tells you what the system should do, but logs tell you what it actually did.” Invest time in good logging practices early — it will save countless hours in debugging and maintenance later. #SpringBoot #Java #BackendDevelopment #Logging #Microservices #SoftwareEngineering

🚀 Spring Boot – User API Upgrade (Full CRUD) Took my mini project to the next level by implementing complete CRUD operations in Spring Boot. 🧠 What I added: ✔️ GET "/users" → Fetch all users ✔️ PUT "/user/{id}" → Update user ✔️ DELETE "/user/{id}" → Delete user 💡 Now the API supports full lifecycle operations: Create • Read • Update • Delete 🔁 Architecture in action: Controller → Service → In-memory data → JSON response 🧪 Tested all endpoints using Postman and verified the complete flow. ⚠️ Also understood the importance of proper error handling (next step: exception handling instead of returning null). 💻 DSA Practice: • Move zeros to end (array manipulation) • First non-repeating character (HashMap concept) ✨ This step helped me understand how real backend systems manage and manipulate data efficiently. #SpringBoot #Java #BackendDevelopment #RESTAPI #CRUD #DSA #LearningInPublic #SoftwareEngineering

🚨 Stop guessing API errors. Read them like a pro. Ever spent 30 minutes debugging… just to realize it was a 400 Bad Request? 😅 👉 Understanding HTTP status codes is not optional. It’s a superpower for every backend & full stack developer. ⚡ API Status Codes — what they REALLY mean: 🟢 2xx = You’re good ✔️ 200 → Everything worked ✔️ 201 → Resource created ✔️ 204 → Success, no content 🔵 3xx = Look somewhere else ➡️ 301 → Permanent redirect ➡️ 302 → Temporary redirect ➡️ 304 → Use cache 🟡 4xx = You messed up (client side) ⚠️ 400 → Bad request (invalid input) 🔐 401 → Not authenticated ⛔ 403 → Not allowed 🔍 404 → Not found ⚡ 409 → Conflict 🧪 422 → Validation failed 🚦 429 → Too many requests 🔴 5xx = Server is crying 💥 500 → Internal error 🌐 502 → Bad gateway 📉 503 → Service unavailable ⏳ 504 → Timeout 🧠 Debug faster with this mindset: ✔️ 2xx → Relax, it’s working ✔️ 3xx → Check URL / caching ✔️ 4xx → Fix your request ✔️ 5xx → Check logs + backend 🔥 Real talk: If you’re building APIs with Spring Boot, Node, or microservices, mastering this = faster debugging + better systems + less stress 💬 Be honest… Which status code wastes most of your time? 😅 #API #Backend #Java #FullStack #WebDevelopment #Debugging #SoftwareEngineering #Microservices #DevTips

Implementing Custom Annotation-Based Logging in Spring Boot. In real-world applications, maintaining clean and reusable logging logic is essential. Instead of adding logging statements in every method, we can leverage Spring AOP and custom annotations to achieve a clean and scalable solution. I recently implemented a custom annotation-based logging mechanism that captures: Method start time Method end time Execution duration All of this is achieved by simply annotating service methods, without modifying business logic. *Key aspects of this implementation*: Custom annotation using @interface Spring AOP with @Around advice Centralized logging using SLF4J Proxy-based interception of method calls This approach helps in: Improving code readability Keeping business logic clean Enabling easy performance monitoring Sharing the implementation document for anyone looking to apply this in their projects. #Java #SpringBoot #AOP #BackendDevelopment #Microservices #CleanCode #SoftwareEngineering

🏗️ Spring Boot Project Structure — What Actually Scales in Real Projects When working on Spring Boot applications, project structure may seem simple at the beginning. But as the project grows, a poor structure quickly turns into hard-to-maintain and messy code 😅 Over time, adopting a clean and structured approach makes a huge difference 👇 🔹 1. Controller Layer Handles API requests & responses — keep it thin, no business logic. 🔹 2. Service Layer (Interface) Defines business operations → improves flexibility & testability. 🔹 3. Service Implementation Contains core business logic → easy to modify without affecting other layers. 🔹 4. Repository Layer Handles DB operations using JPA → clean separation of persistence logic. 🔹 5. Entity Layer Represents database tables → avoid exposing entities directly in APIs. 🔹 6. DTO Layer Used for request/response → better control over API contracts. 🔹 7. Mapper Layer Converts Entity ↔ DTO → avoids repetitive code in services. 🔹 8. Configuration Layer Centralized configs (Security, CORS, Swagger, etc.). 🔹 9. Global Exception Handling Use @ControllerAdvice for consistent error responses. 🔹 10. Utility / Common Layer Reusable helpers (constants, validators, utilities). 🚀 What Changed Everything? Initially, a layer-based structure worked fine. But as the application scaled, switching to a feature-based structure (e.g., user/, payment/, expense/) made it: ✔ Easier to scale ✔ Easier to debug ✔ Easier to maintain 💡 Key Takeaways ✔ A clean structure saves time in the long run ✔ Keep layers loosely coupled ✔ Don’t mix responsibilities 👉 Good architecture isn’t overengineering — it’s future-proofing your codebase. #SpringBoot #Java #BackendDevelopment #SoftwareArchitecture #CleanCode

Day 7 — The API Latency Trap Your API feels fast locally… but suddenly takes 1.2 seconds in production. Here’s what’s really happening 👇 You’re calling multiple external services: • User API • Order API • Payment API Each takes ~400 ms. User user = userClient.getUser(id); Order order = orderClient.getOrder(id); Payment payment = paymentClient.getPayment(id); Looks clean, right? But these calls are sequential. 👉 Total latency = 400 + 400 + 400 = 1200 ms This works fine in testing… but in production, it kills user experience. ⸻ ✅ The Fix: Parallel Calls CompletableFuture<User> userFuture = CompletableFuture.supplyAsync(() -> userClient.getUser(id)); CompletableFuture<Order> orderFuture = CompletableFuture.supplyAsync(() -> orderClient.getOrder(id)); CompletableFuture<Payment> paymentFuture = CompletableFuture.supplyAsync(() -> paymentClient.getPayment(id)); CompletableFuture.allOf(userFuture, orderFuture, paymentFuture).join(); User user = userFuture.join(); Order order = orderFuture.join(); Payment payment = paymentFuture.join(); 👉 Latency drops from 1200 ms → ~400 ms ⸻ 💡 Senior-Level Insight • Don’t rely on default thread pools → use custom executors • Add timeouts + fallbacks (Resilience4j) • Prefer WebClient (non-blocking) for scalable systems ⸻ 🎯 The Lesson Sequential API calls are silent performance killers. Parallelism is not an optimization — it’s a requirement. ⸻ If your service depends on multiple APIs… fix this before production exposes it. ⸻ #BackendDevelopment #Java #SpringBoot #Microservices #SystemDesign #Performance #APIs #DistributedSystems

Lessons from Real Backend Systems Short reflections from building and maintaining real backend systems — focusing on Java, distributed systems, and the tradeoffs we don’t talk about enough. ⸻ We had logs everywhere. Still couldn’t explain the outage. At first, it didn’t make sense. Every service was logging. Errors were captured. Dashboards were green just minutes before the failure. But when the system broke, the answers weren’t there. What we had: [Service A Logs] [Service B Logs] [Service C Logs] What we needed: End-to-end understanding of a single request The issue wasn’t lack of data. It was lack of context. Logs told us what happened inside each service. They didn’t tell us how a request moved across the system. That’s when we realized: Observability is not about collecting signals. It’s about connecting them. At scale, debugging requires three perspectives working together: Logs → What happened? Metrics → When and how often? Traces → Where did it happen across services? Without correlation, each signal is incomplete. The turning point was introducing trace context propagation. [Request ID / Trace ID] ↓ Flows across all services ↓ Reconstruct full execution path Now, instead of guessing: * We could trace a failing request across services * Identify latency bottlenecks precisely * Understand failure propagation Architectural insight: Observability should be designed alongside the system — not added after incidents. If you cannot explain how a request flows through your system, you cannot reliably debug it. Takeaway: Logs help you inspect components. Observability helps you understand systems. Which signal do you rely on most during incidents — logs, metrics, or traces? — Writing weekly about backend systems, architectural tradeoffs, and lessons learned through production systems. Keywords: #Observability #DistributedSystems #SystemDesign #BackendEngineering #SoftwareArchitecture #Microservices #Tracing #Monitoring #ScalableSystems

Spring Boot in Real Projects — Day 19 We already know how APIs return data. But what happens when your application grows and starts handling hundreds or even thousands of tasks daily whether from a single user or many users? For example: User1 → 50 tasks   User2 → 120 tasks   User3 → 300 tasks   It's simple to fetch data for user-1 and next user-2 with 120 tasks gets heavy to fetch and for the next user-3 its hard to fetch and the API response may gets slow, to solve this Pagination & Sorting come in What is Pagination? Pagination is the process of dividing data into smaller chunks (pages) and fetching only the required portion instead of loading everything at once. What is Sorting? Sorting allows us to order data based on a specific field like createdAt, title, etc. Flow Client → Controller → Pageable → Repository → Database (applies LIMIT, OFFSET, ORDER BY) → Returns Page → Response to Client #SpringBoot #Java #BackendDevelopment #Pagination #APIDesign #SoftwareEngineering

In production Spring Boot services, scattered try-catch blocks create inconsistent API behavior. A better approach is centralized handling: ```@RestControllerAdvice public class GlobalExceptionHandler {   @ExceptionHandler(ResourceNotFoundException.class)   public ResponseEntity<ErrorResponse> handleNotFound(ResourceNotFoundException ex) {     return ResponseEntity.status(HttpStatus.NOT_FOUND)         .body(new ErrorResponse("RESOURCE_NOT_FOUND", ex.getMessage()));   }   @ExceptionHandler(MethodArgumentNotValidException.class)   public ResponseEntity<ErrorResponse> handleValidation(MethodArgumentNotValidException ex) {     return ResponseEntity.status(HttpStatus.BAD_REQUEST)         .body(new ErrorResponse("VALIDATION_ERROR", "Invalid request payload"));   }   @ExceptionHandler(Exception.class)   public ResponseEntity<ErrorResponse> handleGeneric(Exception ex) {     return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)         .body(new ErrorResponse("INTERNAL_ERROR", "Unexpected error occurred"));   } }``` Benefits we observed: - Consistent contract for error payloads - Cleaner controllers/services - Accurate HTTP semantics (400, 404, 409, 500) - Better observability and incident response A strong error model is part of API design, not just exception handling. #SpringBoot #Java #Microservices #API #SoftwareEngineering #Backend